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ABSTRACT 


For  sensor  netting  in  ballistic  missile  defense  (BMD) ,  data  must 
be  transferred  from  one  sensor  to  another.  The  purpose  of  the  field 
demonstrations  reported  here  was  to  demonstrate  specific  netting  func¬ 
tions  entailing  data  transfer  from  one  radar  to  another  remotely  located 
radar  under  field  conditions.  At  the  White  Sands  Missile  Range,  target 
data  from  various  objects  were  transferred  from  AMRAD,  a  mechanical 
tracking  radar,  to  HAPDAR,  a  phased  array  radar  driven  by  an  IBM  360/65 
computer  using  special  BMD  software.  The  two  radars  were  separated  by 
about  ten  miles. 


This  report  describes  the  software  developed  for  these  demonstrations 
and  the  tests  that  were  carried  out  to  demonstrate  target  transfer  from 
one  radar  to  another  and  target  track  association  or  correlation  be¬ 
tween  independent  tracks  of  the  two  radars. 
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I  INTRODUCTION 


In  previous  netting  studies1*  the  importance  of  demonstrating  in 
real  time  the  transfer  rget  data  from  one  radar  to  another  and  the 

correlation  of  that  dat  the  radar  data  already  in  the  track  file 

of  the  other  radar  was  ab,  shed.  Any  sensor  netting  scheme  must  trans¬ 
fer  data  from  one  sensor  co  another.  Also,  when  a  second  sensor  receives 
data  from  a  first  sensor,  it  is  necessary  for  the  second  sensor  to  de¬ 
termine  if  the  target  data  it  has  received  is  associated  with  objects 
already  in  its  track  data  file.  If  it  is,  the  data  might  be  used  to 
lessen  the  uncertainty  of  the  target  characteristics.  If  it  is  not,  a 
new  track  should  be  established  on  the  target. 

It  is  important  that  an  ABM  system  efficiently  process  data  so  as 
to  conserve  both  the  time  and  the  resources  devoted  to  the  system’s 
various  functions.  For  target  correlation,  the  track  file  should  be 
rapidly  searched  for  any  target  associations.  For  target  handover,  no 
time  should  be  lost  in  establishing  a  track  on  a  new  target  designated 
to  be  threatening  by  another  sensor.  That  is,  as  few  radar  pulses  as 
possible  should  be  used  to  acquire  the  target  and  place  it  into  track. 

Last  year,  we  demonstrated  target  handover  in  real  time  from  one 
radar  to  another.2  Because  of  computer  limitations,  we  could  not  demon¬ 
strate  correlation  in  real  Ume.  We  did  develop  a  real-time  revision  of 
the  correlation  algorithm  and  test  its  performance  with  real  data. 


^References  are  listed  at  the  end  of  this  volume. 
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In  the  follow-up  project  reported  here,  we  demonstrated  handover  and 
correlation  in  real  time  using  the  recently  installed  IBM  360/65  computer 
driving  the  HAPDAR  radar.  Target  data  was  supplied  by  the  AMRAD  radar, 
a  mechanically  slewed,  tracking  radar,  located  about  ten  miles  from  HAPDAR 
on  the  White  Sands  Missile  Range. 

During  this  period  we  planned  to  demonstrate  the  transfer  of  a 
limited  search  sector  from  one  radar  to  another.  However,  schedule  slip¬ 
page  at  WSMR  not  under  SRI's  control  precluded  accomplishing  this  task 
during  the  contract  period. 

A  summary  of  the  work  and  our  conclusions  from  the  field  demonstra¬ 
tions  are  presented  in  the  next  chapter.  The  approach  to  the  field 
demonstration  is  then  given,  including  a  description  of  the  hardware  and 
software  used  for  the  tests.  Chapter  IV  describes  the  mission  that  was 
used  to  demonstrate  handover  and  correlation — the  sounding  rocket  Rome-03. 
Chapter  V  describes  the  analysis  of  the  data  from  that  mission. 


II  SUMMARY  AND  CONCLUSIONS 


A.  Introduction 

For  several  years  SRI  has  studied  the  advantages  and  benefits  of 
netting  radars  in  ballistic  missile  defense.  Out  of  these  studies  a 
series  of  field  tests  were  proposed  to  validate  the  netting  concepts  that 
showed  promise.  Target  handover,  defined  as  one  radar  transferring  track 
information  to  another  radar  to  enable  that  radar  to  initiate  target 
tracking,  is  basic  to  most  netting  concepts.  Target  correlation,  defined 
as  comparing  the  radar  data  on  a  target  transferred  from  one  radar  to 
another  radar  with  the  track  file  of  the  latter  radar  to  assess  whether 
the  target  is  already  in  that  track  file  or  not,  is  also  an  important 
function  for  most  netting  concepts. 

Another  concept  that  is  normally  assumed  in  netting  studies  is  the 
transfer  of  an  arbitrary  search  sector  from  one  radar  to  another.  For 
example,  a  fire  ball  "blacks  out"  one  radar,  which  then  calls  in  another 
radar  to  search  behind  the  fire  ball  to  detect  any  threatening  objects. 

The  ABMDA  Field  Test  Facility  located  at  WSMR,  along  with  the  AMRAD 
radar  located  ten  miles  from  the  ABMDA  Field  Test  Facility,  provided  a 
useful  simulation  of  netted  hard  site  defense  radars.  The  HAPDAR  radar 
and  the  IBM  360/65  computer  at  HAPDAR  provided  a  model  of  a  BMD  phased- 
array  radar  driven  by  a  computer  with  BMD  software.  AMRAD,  a  mechanically 
scanned  tracking  radar,  simulated  another  BMD  radar  by  sending  target 
track  data  to  HAPDAR  from  both  its  primary  tracker  and  its  secondary 
range-only  tracker. 

SRI  developed  the  software  package,  AMi'OHAP,  to  scale  and  format  the 
AMRAD  radar  data  to  transmit  it  to  HAPDAR  over  land  lines.  SRI  also 
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developed  the  software  package,  TRANFT,  to  smooth  the  data  at  the  IBM 
360/65  computer  to  form  messages  capable  of  initiating  tracks  on  the  same 
targets  AMRAD  was  tracking. 

In  addition,  SRI  developed  two  other  software  packages  for  installa¬ 
tion  at  the  HAPDAR  IBM  360/65.  The  first,  QUECOR,  used  the  handover  mes¬ 
sages  from  TRANFT  and  the  HAPDAR  track  file,  OTDS,  to  determine  if  any  of 
the  tracks  already  in  the  track  file  were  associated  with  the  current 
handover  message.  This  association  process  is  called  target  correlation. 

The  second  software  package,  SSERCH,  used  the  AMRAD  data  smoothed  by 
TRANFT  to  calculate  the  beam  pointing  positions  to  search  the  AMRAD  desig¬ 
nated  search  sector  with  the  HAPDAR  radar.  The  search  data  base  was 
planned  to  be  updated  periodically  by  using  new  data  from  AMRAD. 

A  set  of  test  plans  was  prepared  to  calibrate  the  handover  system, 
to  test  the  operations  of  handover  and  correlation  on  ballistic  targets 
of  opportunity,  and  to  test  correlation  and  special  search  on  request  on 
radar  calibration  spheres  dropped  from  high  flying  aircraft.  RCA,  the 
software  contractor  at  the  ABMDA  Field  Test  Facility,  had  schedule  slip¬ 
pages  in  integrating  the  BMD  software  with  the  HAPDAR  radar.  Because  of 
these  delays,  it  was  not  possible  to  carry  out  the  complete  set  of  test 
plans.  However,  some  calibration  data  were  collected  and  analyzed,  and 
handover  and  correlation  were  demonstrated  on  a  sounding  rocket,  Rome-03. 

B.  Software  Development 
1.  AMTOHAP 

AMTOHAP  takes  data  from  the  primary  and  secondary  AMRAD  trackers 
and  sends  it  to  the  IBM  360/65  computer  at  HAPDAR  via  the  MILGO  interface 
and  kineplex  modems.  The  program,  which  is  resident  in  the  SDS-920  com¬ 
puter  at  AMRAD,  is  an  intercept  driven  algorithm  that  provides  the  soft¬ 
ware  connection  between  the  AMRAD  and  HAPDAR  radars. 


This  program  was  originally  developed  under  a  previous  contract 
for  ABMDA.  For  the  current  contract  the  program  was  modified  by  elimi¬ 
nating  unnecessary  routines  and  altering  the  program  to  accept  both  the 
primary  and  secondary  trackers'  coordinates. 

Each  120-bit  message  from  this  program  contains  the  track 
identification;  the  track  status;  the  azimuth,  elevation,  and  range  of 
the  target;  the  signal  level  of  the  target;  and  the  time  of  day  the 
message  was  valid.  A  message  on  each  track  was  sent  every  0.1  second 
for  a  total  message  rate  of  20  per  second. 

2.  TRANFT 

TRANFT  takes  the  data  received  from  AMRAD,  converts  it  to 
HAPDAR  coordinates,  smooths  it  with  a  tracking  filter,  using  an  effective 
two  pulse  smoothing,  and  then  gives  the  fitted  data  to  the  HAPDAR  operating 
system.  The  algorithm  requires  about  eight  milliseconds  to  complete  one 
cycle  on  the  IBM  360/65,  a  nominal  one  MIP  machine.  The  total  handover 
delay  is  about  70  milliseconds,  50  milliseconds  for  transmission  of  the 
message  from  AMRAD  to  HAPDAR  and  20  milliseconds  to  compute  and  order  a 
radar  transmission  from  HAPDAR. 

3.  QUECOR 

The  correlation  algorithm,  QUECOR,  determines  on  request 
whether  an  object  (or  objects)  being  tracked  by  one  radar  is  also  being 
tracked  by  a  second  radar.  It  does  this  operation  by  comparing  a  given 
track  from  one  radar  with  the  track  file  of  a  second  radar. 

QUECOR,  installed  in  the  IBM  360/65  computer,  can  compare 
three  tracks  in  the  HAPDAR  track  file  with  one  track  from  TRANFT  in  five 
milliseconds.  This  figure  is  for  closely  spaced  tracks.  With  coarse 
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screening  and  prescreening  to  eliminate  all  but  closely  spaced  tracks, 
the  speed  of  operation  can  be  increased  substantially  for  typical  track 
spacings. 

4.  SSERCH 

SSERCH  is  a  real  time,  field  test  algorithm  that  generates  a 
series  of  beam  pointing  directions  and  range  gates  required  for  HAPDAR 
to  search  a  volume  on  special  request.  This  might  be  the  shadowed 
volume  behind  a  nuclear  fireball  that  temporarily  blocks  out  part  of 
another  radar's  search  volume  (in  our  case  AMRAD). 

SSERCH  was  installed  in  the  tactical  function  library  in  the  IBM 
360/65  at  the  HAPDAR  facility.  SSERCH  was  never  integrated  into  the 
PHSD  system  due  to  the  priority  on  the  handover  and  correlation  software 
integration  and  testing  and  subsequent  delays  in  achieving  that  task. 
Thus,  SSERCH  has  never  been  validated  in  real  time  operation. 

C.  Field  Demonstrations 

Four  sets  of  useful  tracking  data  were  collected  during  the  contract 
period.  The  first,  a  balloon-borne  sphere,  was  launched  about  20  km  due 
north  of  HAPDAR;  it  drifted  southeast  as  it  climbed  in  altitude.  About 
116  seconds  of  recorded  data  was  obtained.  The  rest  of  the  data  was 
collected  during  the  Rome-03  mission.  The  premission  balloon-borne 
sphere  was  recorded  for  73  seconds  at  an  average  range  of  57  km.  The 
Rome  rocket  was  recorded  for  eight  seconds  at  an  elevation  of  70°  and  a 
range  of  170  km.  The  Rome  parachute-borne  payload  was  tracked  for  55 
seconds  at  an  average  range  of  93  km. 
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Calibration 


The  sphere-drop  aircraft  were  not  available  for  a  detailed 

calibration  for  the  handover  experiment;  however,  the  initial  balloon- 

borne  sphere  was  used  for  first  order  calibration.  The  data  on  this 

mission  indicated  a  HAPDAR-relati ve-to-AMRAD  range  bias  of  23  m  short, 

an  angle  bias  of  2.6  millisines  above,  and  an  angle  bias  of  1.8  millisines 
* 

left. 

Because  the  range  bias  was  the  most  critical,  this  bias  was 
corrected  for  the  ROME  mission.  However,  the  Rome-03  mission  showed 
that  a  bias  still  remained;  it  had  a  slope  of  0.49  m  per  km  range,  passing 
through  zero  bias  at  58  km.  So  far  we  have  no  explanation  for  this 
linearly  varying  bias. 

2.  Handover  Results 

On  the  Rome-03  premission  sphere,  out  of  76  attempts,  about  68 
percent  of  the  handovers  resulted  in  first  pulse  acquisition  and  over  98 
percent  in  two  pulse  acquisition.  The  first  pulse  misses  can  be  explained 
by  a  low  setting  of  the  AGC.  Because  of  the  large  clutter  on  the  range, 
RCA  did  not  want  to  operate  the  HAPDAR  receivers  at  high  gain,  creating 
the  possibility  of  too  many  hits  in  the  secondary  tracker  channel.  After 
the  first  miss,  the  receiver  gain  was  increased  3  dB,  resulting  in  nearly 
all  of  the  attempts  at  handover  being  successful  in  two  attempts. 

Handover  on  the  other  targets  was  successful  in  some  instances, 
but  often  the  signal-to-noise  ratios  were  too  low  to  expect  successful 
handover  or  high  clutter  levels  masked  handover. 


*0ne  millisine  is  one  one-thousandth  of  a  sine.  Near  boresight  this  is 
approximately  equal  to  one  milliradian, 
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3. 


Correlation  Results 


Track  data  collected  on  the  Rome-03  premission  sphere  provides 
a  good  demonstration  of  the  operation  of  the  correlation  algorithms  in 
real  time.  During  the  Rome-03  mission  there  was  a  7.5  meters  range  bias 
between  AMRAD ' s  first  and  second  tracker.  Consequently,  although  only 
one  target  was  available,  the  AMRAD  data  appeared  as  if  two  targets  were 
being  handed  over.  The  correlation  measure,  Q,  was  sensitive  to  this 
small  range  separation.  Even  with  uncalibrated  angle  biases  remaining 
and  this  small  range  bias  present,  a  decision  threshold  could  be  selected 
to  result  in  correct  correlation  decisions  almost  90%  of  the  time. 

For  the  Rome  rocket  and  payload,  no  independent  tracks  were 
established  by  I1APDAR.  But,  some  track  data  was  available  from  the  two 
dedicated  HAPDAR  tracks.  These  tracks  were  refreshed  at  an  interval  of 
every  two  seconds.  As  the  new  handover  message  is  generated  it  is  com¬ 
pared  with  the  old  dedicated  track  to  determine  the  degree  of  correlation. 
Since  the  old  dedicated  track  is  many  pulses  old,  it  is  nearly  independent 
of  its  initial  values.  This  produced  tests  of  the  correlation  algorithm 
at  low  signal-to-noise  ratios. 

The  Rome  rocket  data  was  unique,  containing  data  on  two  inde¬ 
pendent  targets.  The  first  tracker  tracked  the  rocket  booster  while  the 
second  tracker  tracked  the  payload.  These  two  targets  were  separated  by 
about  600  meters.  Excellent  discrimination  between  these  two  targets  was 
demonstrated. 

From  these  tests,  we  can  expect  that  separations  of  several 
hundred  meters  between  objects  will  result  in  proper  correlation  decisions 
with  a  high  degree  of  success. 
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D. 


Implications  for  HARDSITE  Defense 


In  our  analytic  studies  of  radar  netting,  we  have  shown  that  shared 
search,  where  several  radars  in  a  defense  module  share  the  task  of 
searching  the  threat  corridor,  can  result  in  an  increase  in  defense  s> s- 
tem  performance.  To  accomplish  this  netting  technique,,  target  handover 
and  target  correlation  are  crucial  to  implementing  the  operation. 

We  have  demonstrated  that  target  handover  and  correlation  can  be 
performed  in  a  satisfactory  manner  on  slow  speed  targets  in  real  time. 
Thus,  from  these  demonstrations,  it  appears  that  the  value  of  shaied 
search  can  indeed  be  realized. 

The  next  step,  a  difficult  one  wo  be  sure,  is  to  demonstrate  netted 
operations  with  ICBM  targets  where  clutter  due  to  tank  break  up,  pene¬ 
tration  aids,  and  ionized  wakes  from  reentry  objects  places  a  severe  load 

on  defense  resources. 


] 
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Ill  APPROACH  TO  FIELD  DEMONSTRATIONS 


A.  Introduction 

The  objective  oi  the  field  experiments  was  to  demonstrate,  in  real 
time,  target  data  handover  from  AMRAD  (a  coherent,  monopulse,  mechanical 
tracking  radar)  to  HAPDAR  (a  multifunction  phased  array  radar).  Both  of 
these  L-band  radars  are  located  in  the  southeastern  section  of  WSMR.  The 
radars  are  separated  by  a  distance  of  about  ten  miles,  as  shown  in  Figure  1. 
Also  shown  in  the  figure  is  the  track  of  a  typical  ATHENA  mission  launched 
from  Green  River,  Utah;  it  approaches  on  an  azimuth  nearly  perpendicular 
to  the  base  line  between  the  two  radars. 

The  geometric  configuration  of  tht  two  radars  approximates  the 
spacings  common  for  HARDSITE  defense  radars  in  a  defense  module.  This 
configuration  permits  the  simulation  of  data  transfer  from  one  radar  to 
another  in  a  defense  module  and  control  of  the  phased  array  radar  based 
on  that  data. 

Two  types  of  operations  common  to  HARDSITE  defense  were  planned.  The 
first  was  precision  track  handover  from  one  radar  to  another.  Here  AMRAD 
tracks  a  target  and  then  transfers  the  raw  track  data  to  HAPDAR  via  a  data 
communications  link.  The  data  is  processed  at  HAPDAR  to  generate  a  pre¬ 
cision  state  vector  in  HAPDAR  coordinates,  which  includes  the  target  po¬ 
sition,  velocity,  and  signal  strength.  The  state  vector  is  first  compared 
with  all  of  the  other  state  vectors  in  the  track  file  to  determine  whether 
or  not  the  handed-over  track  is  already  in  HAPDAR' s  track  file.  After 
this  comparison  is  made,  the  handed-over  state  is  updated  with  radar 
measurements,  initiating  a  track  on  the  object.  This  process  is  called 
target  handover  and  correlation. 
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The  second  operation  that  was  planned  was  search  sector  handover. 
Here  one  radar  designates  a  limited  region  to  be  searched  for  targets  by 
the  other  radar.  The  operation  as  modeled  was  this:  one  radar,  AMRAD, 
transferred  a  sector,  one  beamwidth  wide  and  20  km  in  range,  to  HAPDAR 
for  search  coverage.  After  receiving  the  search  request,  the  data  was 
processed  at  HAPDAR  to  generate  the  special  search  data  file  consisting 
of  beam  positions  and  range  limits  for  the  search.  These  search  orders 
were  then  transmitted  by  the  radar,  and  any  detections  processed  through 
verification  to  track. 

The  handover  system  block  diagram  is  shown  in  Figure  2.  Data  on  two 
radar  targets  are  collected  by  the  AMRAD  radar.  One  is  the  data  from  the 
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FIGURE  2  HANDOVER  SYSTEM  BLOCK  DIAGRAM 
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primary  radar  tracker  and  the  other  is  the  data  from  the  secondary  rar  e- 
only  tracker.  These  data  are  scaled  and  placed  in  the  proper  form  to  be 
loaded  into  the  kineplex  data  modem  by  the  on-site  SDS  920  computer. 

The  data  modem  transmits  the  data  over  dedicated  land  s  at  a 

rate  of  2400  bits/sec.  Each  track  data  point  (azimuth,  elevation,  range, 
and  signal  strength)  requires  120  bits.  Accordingly,  data  from  each 
tracker  is  sent  at  ten  points  per  second. 

At  HAPDAR,  the  data  is  demodulated  in  another  kineplex  modem.  The 
data  is  then  transferred  via  several  pieces  of  equipment — the  range  data 
terminal  (RDT) ,  the  radar  computer  interface  (RCI),  and  the  IBM  2701  com¬ 
munications  controller — to  an  IBM  360/65  computer  in  the  HAPDAR  facility. 

This  IBM  360/65  was  programmed  with  special  IBM  developed,  ballistic 
missile  defense  software.  This  software,  known  as  IBM  post-PHSD,  made 
possible  the  real-time  control  of  the  HAPDAR  radar.  SRI  developed  ad¬ 
ditional  software  to  filter  the  incoming  AMRAD  data,  generate  the  handover 
state  vector,  and  correlate  this  vector  with  the  HAPDAR  target  file.  SRI 
also  developed  the  software  for  generating  a  special  search  data  file  from 
AMRAD  data. 

B.  AMRAD 

The  AMRAD  Measurement  Program  is  an  experimental  investigation  of 
radar  observables  of  reentry  objects.  It  is  conducted  by  RRI  (the  River¬ 
side  Research  Institute)  under  the  sponsorship  of  the  WSMR.  RRI  is  as¬ 
sisted  in  radar  site  operations  by  the  Raytheon  Co.  The  observations 
are  made  using  a  coherent  L-band,  monopulse,  tracking  radar  with  a  high 
degree  of  flexibility  in  the  waveforms  it  can  generate. 

However,  only  the  basic  track  data  were  used  in  the  handover  experi¬ 
ments.  The  characteristics  of  the  radar  are  listed  in  Table  1. 
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Table  1 


AMRAD  RADAR  CHARACTERISTICS 

i 


Frequency 

1300  MHz 

Peak  power 

10  MW 

PRF 

50  per  second 

Antenna  gain 

44.7  dB 

Beamwidth 

0. 9  degrees 

System  effective  noise  temperature 

200°  K 

Compressed  pulse  width 

0.08  ps 

2 

S/N  on  0. 1  m  target  at  100  km 

37  dB 

Range  accuracy 

15  meters 

Azimuth  accuracy 

0. 3  mrad 

Elevation  accuracy 

0. 3  mrad 

,  The  Digital  Recording  and  Timing  System  (DRTS)  at  AMRAD  is  the  central 
timing  source  of  the  radar  complex  and  collects,  records,  and  processes 
data  taken  on  radar  targets.  It  is  organized  around  a  general  purpose 
digital  computer,  the  SDS  Sigma  5,  which  controls  the  generation  of  the 
transmitted  waveform,  the  timing  of  the  samples  of  the  received  echoes, 
and  the  transmission  of  the  data  to  the  recorders. 

Radar  data  under  control  of  the  DRTS  is  supplied  to  another  digital 
computer,  the  SDS  920,  via  the  MILGO  interface  equipment.  A  block  diagram 
of  the  AMRAD/HAPDAR  interface  equipment  is  shown  in  Figure  3.  Further 
details  are  presented  in  Appendix  F.  Signal  amplitude,  azimuth,  elevation, 
range,  and  time  of  day  (1RIG  time)  on  two  targets  are  supplied  to  the 
MILGO  interface  equipment.  In  addition,  synchronization  signals  that  con¬ 
trol  the  transmission  of  the  radar  pulses  are  transmitted  to  the  MILGO 
equipment . 
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MILGO  INTERFACE 


FIGURE  3  PHASE  II  CONFIGURATION  (AMRAD/HAPDAR  INTERFACE) 


From  the  MILGO  equipment  the  data  are  sent  to  the  SDS  920  computer 
for  scaling  and  formatting  for  transmission  to  HAPDAR.  The  program  that 
accomplishes  these  operations  is  described  in  Appendix  A. 

After  the  calculations  are  completed  in  the  SDS  920,  the  processed 
data  are  sent  back  to  the  MILGO  equipment  to  be  placed  in  storage  registers 
for  transmission  to  HAPDAR.  From  the  storage  registers  the  data  is  gated 
into  shift  registers  to  drive  the  kineplex  modem,  a  Collins  Model  210  D, 
for  transmission  by  dedicated  land  lines  to  the  kineplex  modem  at  HAPDAR. 

C.  HAPDAR 

The  HAPDAR  radar  is  a  multifunction  array  radar  designed,  constructed, 
and  operated  by  the  Sperry  Gyroscope  Division  of  Sperry  Rand  Corporation. 

A  good  description  of  the  radar  is  available  in  the  literature.3  Its 
characteristics  are  summarized  in  Table  2. 


Table  2 

HAPDAR  RADAR  CHARACTERISTICS 


Frequency 

1350  MHz 

Peak  power 

2  MW 

PRF 

variable 

Antenna  gain 

35.9  dB 

Antenna  beamwidth 

1.6  degrees 

Pulse  length 

20  ps  chirped  to  10  MHz 

Beamswitch  time 

100  ps 

2 

S/N  on  0.1  m  target  at  100  km 

15  dB 

Range  accuracy 

2.3  meters 

Angle  accuracy 

0.6  mrad 
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The  HAPDAR  radar  is  controlled  by  an  IBM  360/65  computer  that  orders 
radar  transmissions  and  specifies  the  receiver  gates,  thresholds,  and 
attenuations  for  reception  of  the  transmissions.  The  rate  of  transmission 
is  a  variable  under  control  of  the  computer,  but  the  upper  limit  (set  by 
transmitter  constraints)  is  about  300  pulses  per  second.  The  nominal 
rate  for  track  was  20  pps,  and  w-hatever  resources  remained  after  servicing 
all  track  requests  were  allocated  to  search. 

For  the  SRI  experiment,  two  track  channels  were  dedicated  to  tracking 
the  two  targets  designated  by  AMRAD.  The  first  track  channel  was  dedi¬ 
cated  to  the  AMRAD  primary  tracker.  This  first  channel  used  a  split  gate 
tracker  with  a  gate  width  of  ±0.4  sec  and  a  false  alarm  probability  of 
10"2.  The  initial  receiver  attenuation  setting  was  determined  from  the 
predicted  signal  strength  from  the  AMRAD  data. 

The  second  track  channel  was  dedicated  to  the  AMRAD  secondary,  range- 
only  tracker.  This  channel  used  a  split  gate  tracker  with  a  gate  width 
of  ±2  psec  and  a  false  alarm  probability  of  1.6  X  10  .  The  larger  gate 

width  was  required  because  the  uncertainty  of  measurement  was  quite  large 
in  angle  for  the  range-only  tracker.  Here  again  the  initial  receiver 
attenuation  was  set  based  on  the  signal  strength  predicted  from  AMRAD 

measurements. 

The  relative  level  of  the  difference  in  sensitivity  of  AMRAD  and 
HAPDAR  was  measured  on  7  February  1972  by  tracking  a  six-inch  balloon- 
borne  sphere  with  both  radars.  This  measurement  indicated  that  AMRAD 
was  24  dB  more  sensitive.  Because  of  the  possibility  of  locking -up  on 
clutter,  the  predicted  signal  strength  was  scaled  by  -23  dB  rather  than 
-24  dB,  leaving  a  1-dB  margin. 

Besides  the  dedicated  track  channels,  HAPDAR  conducted  a  search 
about  the  two  targets  designated  by  AMRAD.  In  this  way,  it  was  hoped  to 
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generate  tracks  for  HAPDAR 's  track  file  that  could  then  be  correlated 
with  the  state  vectors  of  the  handed-over  targets. 

D.  IBM  360/65 

In  early  1972,  ABMDA  installed  an  IBM  360/65  general  purpose  digital 
computer  at  HAPDAR  as  a  part  of  the  ABMDA  Data  Processing  Field  Test 
Facility.  This  third  generation  machine  has  a  memory  cycle  time  of 
0.75  nsec  and  a  million  words  of  central  processor  memory.  It  uses 
eight  bits  per  byte  and  four  bytes  to  the  word.  Its  execution  speed  for 
a  fix  point  addition  is  1.3  nsec. 

RCA,  as  the  operating  contractor  at  the  Data  Processing  Field  Test 
Facility,  modified  the  ABMDA  supplied  baseline  software  and  installed 
this  modified  software  to  permit  real-time  control  of  the  HAPDAR  radar. 

The  baseline  software  known  as  post-PHSD  was  developed  for  ABMDA 
by  IBM  in  order  to  demonstrate  that  commercially  available  hardware  and 
software  could  be  tailored  to  satisfy  the  requirements  of  ballistic  mis¬ 
sile  defense  data  processing.  IBM  developed  a  real-time  control  program/ 
operating  system  known  as  BMDOS  and  designed  and  implemented  the  software 
for  tactical  algorithm  and  process  construction  for  BMD.  This  develop¬ 
ment  is  described  in  a  nine  volume  report. 

For  this  contract,  SRI  developed  or  modified  several  algorithms  for 
use  in  processing  handover  data  from  AMRAD.  These  algorithms,  which  aie 
described  in  the  next  section,  were  integrated  into  the  tactical  process 
of  the  post-PHSD  by  RCA.  A  description  of  the  post-PHSD  SRI  handover 
software  interface  is  given  in  Appendix  E.  This  software  combination 
permitted  the  IBM  360/65  computer  to  control  the  HAPDAR  radar  in  (1) 
search,  target  verification,  track  initiation,  and  track  and  (2)  acquisi¬ 
tion  of  target  tracks  based  on  AMRAD  data. 
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E. 


SRI  Software  Development 


1 .  I ntroduction 

A  block  diagram  of  the  AMRAD-to-HAPDAR  handover,  correlation, 
and  search  system  is  shown  in  Figure  4.  The  program  AMTOHAP,  which  re¬ 
sides  in  AMRAD ' s  SDS  920,  receives  interrupts  from  the  AMRAD  radar;  the 
program  responds  to  these  interrupts  by  either  inputting  data  measure¬ 
ments  from  the  AMRAD  radar  or  outputting  them  to  the  HAPDAR  radar.  (The 
program  AMTOHAP  is  described  in  Appendix  A.)  The  signals  sent  to  HAPDAR 
travel  via  the  kineplex  link,  the  RDT,  the  RCI,  and  the  parallel  data 
adapter  (PDA).  An  RCA  channel-control  program  then  reads  the  data  into 
fast  memory — that  is,  the  AMItAD  data  file — from  the  PDA. 

The  SRI  program  TRANFT  takes  the  data  from  the  AMRAD  data  file, 
converts  it  to  HAPDAR  coordinates,  and  fits  it  with  appropriate  filtering 
algorithms.  Following  transformation  and  fitting,  the  program  TRANFT 
outputs  the  filtered  data  to  an  AMRAD  track  file  and  a  QUECOR  data  file. 
The  AMRAD  track  file  is  used  by  the  HAPDAR  radar  to  initialize  the  two 
channels  it  has  dedicated  to  handover  messages.  Similarly,  the  QUECOR 
data  file  is  used  to  provide  information  for  correlating  AMRAD  and  HAPDAR 
tracks  with  QUECOR,  as  well  as  to  generate  search-sector  requests  by 
SSERCH  for  the  HAPDAR  radar.  (All  the  input  and  output  from  TRANFT, 
QUECOR,  and  SSERCH  occurs  via  FORTRAN  subroutines. ) 

2.  HAPDAR  Software  for  SRI  Experiment 

The  block  diagram  in  Figure  5  indicates  the  software  developed 
by  SRI  and  RCA  to  accomplish  the  handover  experiments.  RCA  wrote  the 
programs  to  take  the  AMRAD  data  from  the  RCI  to  the  AMRAD  data  file,  RSDS, 
in  the  IBM  360/65  computer. 

SRI  developed  the  three  programs  TRANFT,  QUECOR,  and  SSERCH. 
TRANFT  smooths  the  AMRAD  data,  QUECOR  correlates  the  AMRAD  data  with  the 
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FIGURE  5  HAPDAR  SOFTWARE  FOR  SRI  HANDOVER  EXPERIMENT 


track  file  (OTDS),  and  SSERCH  generates  search  beam  positions  for  limited 
sector  search  handover. 

To  integrate  these  programs  with  the  other  software,  RCA  de¬ 
veloped  SRIBLD,  DTTSRI  and  MPFCOV.  SRIBLD  took  the  current  state  vector 
from  AMTRK,  a  data  set  constructed  by  TRANFT,  and  initially  built  an 
instance  in  the  track  file,  OTDS,  or  reinitialized  the  track  in  OTDS. 

DTTSRI  was  a  special  a-p  track  routine  designed  to  update  the  tracks  in 
the  dedicated  track  channels.*  The  covariance  for  both  the  dedicated 
tracks  and  the  other  tracks  in  the  OTDS  using  cy-p  tracking  was  calculated 
by  MPFCOV.  This  calculation  was  identical  to  the  method  used  by  TRANFT 
(see  Appendix  B) . 

The  constants  for  the  cy-p  range  trackers  were  a  =  0. 8  and 
p  =  0.15,  and  for  the  cy-P  angle  trackers  were  or  =  0.25,  p  =  0.1.  A  Type  1 
filter  was  used  for  AGC  with  a  =  0.5. 

3.  Program  TRANFT 

The  program  TRANFT  converts  the  data  received  from  the  AMRAD 

radar  to  HAPDAR  coordinates  and  then  filters  the  resulting  coordinates 

for  a  vehicle  state  vector  and  error  covariance  matrix.  The  program 

begins  its  transformation  and  fitting  operations  by  inputting  data  from 

the  AMRAD  data  file.  This  data  includes  the  measured  position  coordinates 

range,  elevation  angle,  and  aximuth  angle  (R,  E,  and  A),  the  range  time 

(t  )  the  signal-to-noise  ratio  (SNR),  the  data  source  (PAS  or  AMRAD), 
new  ’  ,  ,  . 

the  target  number  (primary  or  secondary),  and  the  tracking  mode  (manua  , 

acquisition,  autotrack).  Following  inputting  of  the  AMRAD  data,  TRANFT 


*For  a  description  of  cy-B  trackers  see  Ref.  5. 
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makes  an  immediate  validity  check  (is  t  >  t  ,)  and  returns,  without 

new  old 

processing  the  data,  to  the  operating  system  if  new  data  has  not  been 
received . 

The  program  TRANFT  next  converts  the  AMRAD  R,  E,  and  A  measure¬ 
ments  to  equivalent  HAPDAR  R,  u,  and  v  measurements,  where  u  and  v  are 
direction  cosines.  (The  conversion  routine  was  developed  under  the  pre¬ 
vious  contract  work  and  has  been  described  in  Ref.  2.  )  The  vehicle 

state  vector,  Z  ,  is  next  updated  from  time  t  to  t  with  the  transi- 
7  e  old  new 

tion  matrix  F.  The  updated  or  "predicted”  state  vector,  Z-  ,  is  then 

P 

corrected  using  the  transformed  AMRAD  measurements  Z  and  a  new  estimated 

m 

state  vector,  Z^,  thereby  formed. 

The  program  TRANFT  next  updates  the  error  covariance  matrix, 

E  using  the  same  transition  matrix  F.  Following  the  updating  operation, 
e 

the  measured  errors  Z  -  Z  are  calculated,  and  a  measured  error  covari- 

m  p 

ance  matrix,  E  ,  defined.  The  measured  error  covariance  matrix  is  then 
m 

averaged  with  the  predicted  one,  E  ,  and  a  new  estimated  error  covariance 
matrix  obtained.  Following  the  above  operations,  the  program  TRANFT  out¬ 
puts  the  estimated  vehicle  position,  the  estimated  vehicle  velocity,  the 
estimated  AGC  level,  the  track  ID,  and  the  time-of-validity  to  the  AMRAD 
track  file.  Similarly,  the  estimated  state  vector,  estimated  error  co- 
variance  matrix,  track  ID,  and  time-of-validity  are  outputted  to  the 
QUECOR  track  file. 

A  complete  description  of  the  program  is  given  in  Appendix  B. 

1.  Program  QUECOR 

QUECOR  attempts  to  discover  which  tracks  from  the  HAPDAR  track 

file  are  correlated  with  the  current  track  in  the  AMRAD  track  file.  This 

th 

is  accomplished  by  computing  a  correlation  parameter  Q  for  the  i 
th 

AMRAD  track  and  j  HAPDAR  track.  A  threshold  is  compared  to  each 
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Q  for  each  i 

ij 

relation 
tween 
exist? 
is  cox'! 


and  for  all  j.  A  Q  greater  than  Qt  indicates  a  decor- 

“*■  J 

less  than  Qt  indicates  a  possible  correlation  be¬ 
nd  HAPDAR  track  j.  Thus,  if  for  a  given  i,  there 
that  Q  is  less  than  Q  ,  we  say  that  AMRAD  track  1 

ij  1 

■\R  track  j. 


The  correlation  parameter  Q.  .  is  a  function  of  the  vector  dif¬ 
ference  between  the  estimated  position  vector  of  AMRAD  track  i  and  the 
predicted  position  vector  (i.e.,  predicted  to  the  corresponding  time  of 
the  AMRAD  track  estimate)  of  HAPDAR  track  j.  It  is  also  a  function^ 
the  covariance  matrix  for  this  position  difference  vector.  Let  ^  be 
the  elements  of  the  inverse  of  this  covariance  matrix,  and  J  be  H 

mth  coordinate  of  the  position  difference  vector.  Then  we  define 


‘ij 


„  ij  .  ij  .  ij 

C  Ax  Ax 
mn  m  n 


m,  n=l 


vVhen  QUECOR  is  called,  the  first  task  is  to  obtain  data  from 
the  AMRAD  track  file  that  will  contain  only  one  track.  This  data  will 
be  the  latest  handed  over  information.  The  subset  of  this  data  requued 
by  QUECOR  consists  of  the  estimated  position  coordinates  of  the  tracked 
object,  the  corresponding  three-by-three  covariance  matrix,  and  the  time 
for  which  the  estimate  is  made.  QUECOR  next  obtains  the  data  from  the 
first  HAPDAR  track  file.  This  data  consists  of  the  estimated  position 
and  velocity,  the  corresponding  six-by-six  covariance  matrix,  and  the 
time  for  the  estimate. 

The  HAPDAR  track  position  and  position  covariance  matrix  (i.e., 
a  three-by-three  submatrix)  are  updated  to  the  AMRAD  track  time.  The 
position  difference  vector  and  its  magnitude  are  then  computed,  and  the 
two  position  covariance  matrices  are  summed.  Next,  an  upper  bound  on 
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the  largest  eigenvalue  of  this  summed  matrix  is  obtained  by  analyzing 
the  diagonal  elements  and  the  magnitude  of  the  off-diagonal  elements. 

The  ratio  of  the  magnitude  of  the  difference  vector  and  the  bound  on  the 
largest  eigenvalue  of  the  covariance  matrix  forms  a  lower  bound  on  Q.  If 
this  lower  bound  exceeds  Qt,  then  its  value  is  stored  in  an  array  and  a 
flag  is  set  in  the  corresponding  element  of  a  corresponding  array  to  de¬ 
note  that  the  pair  of  tracks  are  decorrelated,  and  that  this  was  deter¬ 
mined  by  a  lower  bound  calculation.  When  this  happens,  QUECOR  proceeds 
to  the  next  HAPDAR  track  and  repeats  the  process. 

In  case  the  lower  bound  on  Q  is  below  Qt,  the  exact  value  of  Q 
must  be  calculated.  This  is  done  by  first  inverting  the  covariance  ma¬ 
trix  and  then  computing  Q  by  Eq.  (1).  Again  Q  is  compared  to  and  if 

greater  its  value  is  stored  in  the  Q  array  and  a  second  type  of  flag  is 
set  in  the  flag  array  to  denote  the  decorrelation  and  the  fact  that  Q 
was  computed  exactly.  In  case  Q  is  less  than  Qt  it  is  also  stored  in  the 
Q  array  and  a  third  type  of  flag  is  set  in  the  flag  array  to  denote  the 
possible  correlation.  QUECOR  then  proceeds  to  the  next  HAPDAR  track  and 
repeats  the  process.  Finally,  when  all  HAPDAR  tracks  are  exhausted, 
QUECOR  examines  the  flag  array  to  determine  if  only  one  correlation  flag 
is  set.  If  so,  then  the  index  of  that  flag  representing  the  identifica¬ 
tion  number  of  the  HAPDAR  track  is  stored  to  indicate  the  correlation. 
Control  of  the  CPU  is  then  returned  to  the  calling  control  program.  Note 
that  no  real-time  operation  of  the  radar  systems,  nor  any  other  tactical 
function,  requires  the  outputs  of  QUECOR  for  the  real-time  field  test. 
Thus,  the  outputs  of  QUECOR  are  simply  stored  and  recorded  for  subsequent 
analysis. 

A  complete  description  of  QUECOR  is  given  in  Appendix  C. 
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5. 


Program  SSERCH 


SSERCH  generates  a  series  of  beam  pointing  directions  and  range 
gates  required  for  HAPDAR  to  search  the  volume  behind  a  nuclear  fireball 
that  temporarily  blocks  out  part  of  the  AMRAD  search  volume.  When  SSERCH 
is  called,  the  fireball  is  simulated  within  SSERCH  by  specifying  a  fire¬ 
ball  radius  and  range  along  the  line-of-sight  from  AMRAD  to  the  most  re¬ 
cent  handed  over  state  vector  position  coordinates.  This  range  is  set 
at  a  fixed  distance  in  front  of  the  handed  over  point.  The  fireball  ra¬ 
dius  is  also  set  at  a  constant  value.  The  search  volume  is  taken  to  ex¬ 
tend  from  the  front  edge  of  the  fireball  to  a  maximum  range  defined  by 
adding  a  fixed  distance  behind  the  simulated  fireball.  This  maximum  range 
corresponds  to  the  limit  to  a  tactical  search  sector  for  AMRAD. 

SSERCH  computes  the  direction  of  the  simulated  fireball  from 
HAPDAR  and  takes  this  as  the  first  required  search  beam  direction,  pro¬ 
vided  it  falls  within  the  of f-boresight  limits  for  HAPDAR.  If  this  con¬ 
dition  is  not  met,  a  flag  is  set  that  indicates  that  part  or  all  of  the 
required  search  volume  falls  outside  the  HAPDAR  limits.  However,  new 
beam  directions  continue  to  be  generated  in  case  some  of  the  later  beam 
directions  are  feasible.  Whenever  the  flag  described  above  is  set, 

SSERCH  bypasses  the  calculation  of  the  corresponding  range  gates  and  the 
setting  of  the  beam  coordinates  into  storage. 

Each  new  beam  is  generated  recursively  from  the  previous  beam 
direction  by  requiring  the  new  beam  direction  to  intersect  the  line-of- 
sight  from  AMRAD  to  the  simulated  fireball.  In  addition,  the  distance 
along  this  line-of-sight  (between  the  two  intersection  points  of  the  new 
and  old  beam)  is  required  to  be  such  that  there  is  an  overlap  between  the 
3-dB  contours  of  the  beams.  This  overlap  is  specified  in  the  sine  space 
of  HAPDAR  where  circles  of  constant  radius  define  the  beam  contours,  by 
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requiring  the  distance  between  the  beam  centers  to  be  less  than  the 
diameter  of  the  beam  3-dB  circle. 

Given  the  new  or  next  beam  direction,  a  minimum  and  a  maximum 
range  is  computed  so  that  the  region  specified  by  the  intersection  of  the 
beam  and  the  shadow  tube  of  the  fireball  is  included  between  the  range 
limits.  Provided  that  the  beam  direction  is  within  the  of f-boresight 
limits  of  HAPDAR,  the  values  of  sin  a,  sin  g,  the  minimum  range,  and  the 
maximum  range  are  stored  for  later  transfer  to  the  special  search  sector 
data  set. 

Beam  directions  are  generated  until  the  range  of  the  intersection 
of  a  generated  beam  and  the  line-of-sight  from  AMRAD  to  the  fireball  ex¬ 
ceeds  the  previously  determined  maximum  range.  This  beam  direction  then 
becomes  the  last  beam  generated.  However,  in  the  case  where  at  least  one 
beam  is  generated  within  the  of f-boresight  limits  of  HAPDAR  and  some  sub¬ 
sequent  beam  falls  outside  these  limits,  the  beam  generation  process  is 
terminated  when  the  of f-boresight  limit  is  exceeded.  As  before,  a  flag 
is  set  to  indicate  that  the  beams  generated  do  not  form  a  complete  set. 

In  any  case  when  beam  generation  ceases,  the  beam  pointing  co¬ 
ordinates  are  transferred  to  the  search  sector  file,  and  control  of  the 
CPU  is  transferred  back  to  the  calling  function. 

A  complete  description  of  SSERCH  is  given  in  Appendix  D. 

F.  Demonstration  of  Handover,  Correlation,  and  Special  Search 

A  test  plan  for  field  demonstration  of  target  handover,  correlation, 
and  special  search  on  request  was  prepared. 6  The  plan  included  a  method 
for  calibrating  the  HAPDAR  radar. 
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1. 


Calibration 


It  was  necessary  to  calibrate  the  handover  system  to  determine 
the  magnitude  and  source  of  any  static  range  and  angle  biases.  To  ac¬ 
complish  this  calibration,  the  plan  was  to  drop  four  12-inch  calibration 
spheres  from  an  aircraft  at  the  WSMR.  The  drops  were  to  be  as  follows: 
one  of  the  spheres  at  ORV,  about  50  km  in  front  of  HAPDAR;  one  at  George 
site,  where  the  AMRAD  line-of-sight  is  perpendicular  to  the  HAPDAR  line- 
of-site;  and  one  each  at  Bell  and  UPDOC,  to  the  left  and  right  of  HAPDAR 's 
boresight,  to  check  azimuth  sensitivity. 

Because  of  delays,  the  sphere  drop  aircraft  were  not  available 
for  calibration.  Data  from  two  balloon-borne  spheres  launched  about  20  km 
due  north  of  HAPDAR,  near  the  boresight  azimuth,  were  used  for  calibration. 
The  winds  carried  the  spheres  east  as  they  climbed  in  altitude.  Data 
from  these  spheres  were  used  to  calibrate  the  range  bias,  the  most  criti¬ 
cal  bias  for  target  handover.  There  was  not  an  adequate  spread  in  angle 
to  calibrate  the  angle  channels. 


2.  Demonstration  of  Handover  and  Correlation 

Two  kinds  of  demonstration  were  planned  to  demonstrate  target 
handover  and  correlation.  The  first  was  the  demonstration  of  handover  of 
ballistic  targets  of  opportunity  from  AMRAD  track  to  HAPDAR  track  without 
HAPDAR  searching  for  the  target,  and  demonstration  of  the  SRI  developed 
track  correlation  algorithm  using  the  handover  track  and  the  HAPDAR  track 
file. 

In  these  tests,  taigets  of  opportunity  (such  as  PERSHING, 
sounding  rockets,  and  preferably  ATHENA,  an  ICBM  reentry  simulation  fired 
from  Green  River,  Utah)  would  be  tracked  by  AMRAD,  with  both  the  DRTS  I 
and  II  trackers.  If  there  was  any  other  object  separated  from  the  pri¬ 
mary  target,  the  range  only  tracker,  DRTS  II,  would  be  placed  on  that 
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object.  This  track  data  would  then  be  sent  to  HAPDAR,  which  would  search 
about  the  targets  to  generate  targets  for  its  track  file. 

For  handover  and  correlation,  two  of  HAPDAR's  track  channels 
were  dedicated  to  initializing  on  the  smoothed  handover  data.  These  two 
channels  were  maintained  in  track  at  20  pps.  Every  two  seconds,  these 
track  channels  were  reinitialized  with  data  from  the  handover  track  file. 

The  plan  called  for  the  independent  tracks  in  the  nondedicated 
channels  to  be  tracked  at  20  pps  also.  The  state  vectors  and  covariances 
of  each  target  were  maintained  in  the  track  file  at  HAPDAR.  At  handover 
times,  once  every  second,  the  correlation  measure,  Q,  was  calculated 
using  the  data  from  the  HAPDAR  track  file  and  the  handover  target  state 
and  covariance. 

The  second  test  was  designed  to  demonstrate  the  ability  of  the 
SRI  correlation  algorithm  to  distinguish  a  particular  target  designated 
by  AMRAD  within  a  group  of  closely  spaced  radar  targets.  For  this  test, 
four  12-inch  calibration  spheres  were  to  be  dropped  from  an  aircraft 
flying  at  40,000  feet.  The  spheres  were  to  be  dropped  at  a  rate  of  one 
eve  ry  three  seconds  to  form  a  group  of  radar  targets  spaced  about  500 
meters  apart.  AMRAD  would  designate  one  of  the  spheres  to  HAPDAR.  Pre¬ 
viously,  HAPDAR  would  have  searched  and  acquired  the  four  spheres  and 
the  aircraft.  The  sphere  designated  by  AMRAD  would  then  be  correlated 
with  the  five  objects  in  HAPDAR's  track  file  to  identify  the  object 
designated  by  AMRAD. 

Because  the  sphere  drop  aircraft  was  not  available,  the  demon¬ 
stration  of  target  correlation  with  closely  spaced  spheres  was  not  ac¬ 
complished.  The  only  ballistic  target  of  opportunity  that  HAPDAR  was 
able  to  track  using  the  IBM  360/65  computer  during  the  contract  period 
was  a  sounding  rocket,  Rome-03.  This  mission  is  described  in  the  next 
chapter  and  the  results  are  analyzed  in  Chapter  V. 
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3. 


Demonstration  of  Special  Search  on  Request 


The  objective  of  the  demonstration  of  Special  Search  on  Request 
was  to  demonstrate  the  ability  of  a  radar  to  search  an  arbitrary  search 
sector  on  request  of  another  remotely  located  radar,  as  might  occur  if 
the  remote  radar  were  "blacked  out"  by  a  fireball  obscuring  a  region  in 
its  search  sector.  To  accomplish  this  demonstration,  12-inch  spheres 
were  to  be  dropped  in  selected  locations.  AMRAD  would  track  each  sphere 
to  determine  the  direction  of  the  simulated  obscured  region.  This  direc¬ 
tion  would  be  communicated  to  the  HAPDAR  IBM  360/65  computer  via  the  data 
link.  At  the  360/65  the  special  search  algorithm  would  generate  a  search 
position  data  set  along  the  line  segment  directed  from  AMRAD  to  the  tar¬ 
get,  20-km  in  length  and  centered  on  the  target.  This  line  would 
searched  once  every  second  with  the  search  continuing  for  ten  seconds. 
After  ten  seconds  the  search  would  be  reinitialized  from  a  new  designation 
message  from  AMRAD.  The  search  hits  would  be  recorded  during  the  special 
search  to  demonstrate  that  the  search  was  conducted  properly. 

Again  this  demonstration  could  not  be  completed  because  the 
sphere  drop  aircraft  were  not  available  and  also  there  was  not  enough 
time  available  to  complete  checkout  of  the  special  search-on-request 


algorithm. 


IV  ROME -03  TEST  DESCRIPTION 


On  28  February  1973,  handover  and  correlation  on  a  moderate  velocity 
target  was  accomplished.  On  this  day,  at  13:27:00  GMT,  a  sounding  rocket 
(SRW-04/Rome-03)  was  fired  from  WSMR  Launch  Complex  33.  AMRAD  tracked 
this  target  throughout  most  of  its  trajectory  with  both  the  trackers 
using  centroid  tracking.  AMRAD  data  during  this  flight  were  used  to 
hand  targets  over  to  the  HAPDAR  radar  and  to  correlate  the  handover  data 
with  the  HAPDAR  track  file.  In  addition,  AMRAD  tracked  a  premission, 
balloon-borne  12-inch  diameter  sphere  and  also  handed  this  target  over 
to  HAPDAR. 

To  describe  this  mission,  pertinent  data  have  been  extracted  from 
the  AMRAD  data  summary.7  The  Rome-03  payload  was  boosted  by  a  NIKE-HYDAC 
rocket  to  an  altitude  of  165.8  km  where  a  small  aerosol  cannister  was 
ejected,  subsequently  releasing  a  disc-shaped  cloud  of  carbon  particles. 
After  cannister  release,  the  payload  was  separated  from  the  booster, 
followed  by  parachute  deployment  to  slow  the  descent  of  the  payload  for 
recovery. 

Figure  6  shows  the  ground  track  as  recorded  by  AMRAD,  with  the  times 
of  significant  events.  Figure  7  shows  thp  flight  profile.  Figure  8 
shows  the  velocity  history  of  the  target  and  Figure  9  shows  the  target 
coordinates  in  range,  azimuth,  and  elevation  relative  to  AMRAD. 

The  radar  cross  section  has  been  calculated  from  tbe  AMRAD  radar 
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precursor  pulse  returns,  averaged  over  0.1  sec,  or  five  pulses.  Figure  10 


The  precursor  pulse  was  6  MW  and  1.2  psec. 

33 

preceding  page  blank-not  filmed 


Target  ground  track  derived  from  AMRAD  tracking  date 
Itmoothed  over  3  >  in  range  and  5  i  in  angle). 
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FIGURE  7  ROME-03  FLIGHT  PROFILE 
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NOTE:  Gaps  in  curve  indicate  tracking  perturbations. 

DATA’  Target  velocity  history  from  AMRAD  tracking  data 
(smoothed  over  3  s  in  range  and  5  s  in  angle). 
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FIGURE  8  ROME-03  VELOCITY  HISTORY 
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FIGURE  10  ROME-03  AVERAGE  TARGET  RCS 
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shows  a  plot  of  the  radar  cross  section  as  a  function  of  the  time  after 
lift  off.  The  premission  sphere  calibration  shows  the  calibration  con¬ 
stant  used  in  these  computations  to  be  within  1  dB  of  the  measured  value. 
Also  shown  in  the  figure  is  the  equivalent  cross  section  of  the  minimum 
discernible  signal  (MDS)  at  the  range  of  the  target.  Considering  that 
HAPDAR  has  about  24  dB  less  sensitivity  than  AMRAD,  it  can  be  seen  that 
the  signal-to-noise  ratios  at  HAPDAR  were  quite  low  for  Rome-03. 

The  I  P  pulse  transmitted  by  AMRAD  consisted  of  a  six  megawatt 
0.1  l-isec  pulse  repeated  50  times  per  second.  The  returns  from  this  pulse 
were  used  to  produce  the  range-time-intensity  (RTI)  record  shown  in 
Figure  11.  Here  only  a  selected  portion  is  shown;  the  time  is  labeled 
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FIGURE  11  AMRAD-IP  RTI  RECORD 


in  HAPDAR  mission  time,  with  lift-oil  corresponding  to  2590.7  seconds. 
HAPDAR  collected  data  during  the  period  2821.5  to  2829.5  seconds.  It 
can  be  seen  that  there  are  three  targets  visible  during  this  period. 
The  target  in  track  is  the  Rome-03  rocket;  the  target  farther  in  range 
is  probably  the  nose  cone.  The  target  nearer  in  range  diverging  from 
the  rocket  is  probably  the  canister.  Thus  during  the  period  of  the 
demonstration  there  were  three  targets  available;  however,  all  three 
were  so  low  in  radar  cross  section  that  HAPDAR  could  not  independently 
acquire  any  of  them. 


V  DATA  ANALYSIS 


A.  Description  of  Data 

Four  sets  of  useful  tracking  data  were  obtained  during  the  contract 
period.  The  first  set  of  data  was  a  track  of  a  balloon  launched  sphere 
which  took  place  on  2  February  1973.  The  total  track  duration  extended 
over  a  period  of  about  262  seconds;  data  was  recorded  from  five  segments 
of  this  period,  covering  a  duration  of  about  116  seconds.  For  convenience 
we  will  refer  to  this  particular  sphere  as  Sphere  One.  The  ground  track 
for  Sphere  One  is  shown  in  Figure  12.  The  average  range  and  elevation 
relative  to  HAPDAR  was  18,000  meters  and  24°.  The  azimuth  varied  from 
13.8°  to  31°  relative  to  HAPDAR.  The  elevation  relative  to  AMRAD  was 
greater  than  24°  since  the  ground  range  relative  to  AMRAD  was  much  less 
than  to  HAPDAR. 

The  remaining  sets  of  data  were  taken  on  28  February  1973,  and  were 
associated  with  the  Rome-03  mission  described  in  Chapter  IV.  The  first 
set  of  data  was  from  a  premission  balloon-launched  sphere,  the  second 
from  the  Rome-03  rocket,  and  the  third  from  the  parachuted  Rome-03  in¬ 
strumentation  package  toward  the  end  of  the  mission.  We  will  refer  to 
these  objects  and  their  track  data  as  the  Rome  Sphere,  the  Rome  Rocket, 
and  the  Rome  Payload,  respectively. 

The  track  on  the  Rome  Sphere  started  at  654  seconds  into  the  mission 
time,  covered  a  period  of  289  seconds,  and  data  was  recorded  from  three 
segments  of  this  period  covering  a  duration  of  73  seconds.  The  ground 
track  for  the  Rome  Sphere  is  shown  in  Figure  13.  The  average  range  and 
elevation  relative  to  HAPDAR  was  57,300  meters  and  12  .  The  azimuth 
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UPRANGE 


FIGURE  12  SPHERE  ONE  GROUND  TRACK 


varied  from  4.5°  to  15.8°  relative  to  HAPDAR.  The  elevation  relative 
to  AMRAD  was  greater  than  12°  since  the  ground  ranges  relative  to  AMRAD 
were  less  than  to  HAPDAR. 

The  track  on  the  Rome  Rocket  covered  a  period  of  eight  seconds, 
starting  from  2821.5  seconds  into  the  mission  time.  The  data  consisted 
of  only  one  segment.  The  ground  track  for  the  Rome  Rocket  is  shown  in 
Figure  14.  The  average  range,  elevation,  and  azimuth  relative  to  HAPDAR 
were  170,000  meters,  70°,  and  -18°,  respectively.  Since  the  ground 
range  relative  to  AMRAD  was  slightly  less  than  the  ground  range  from 
HAPDAR,  the  elevation  relative  to  AMRAD  was  slightly  greater  than  70  . 
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FIGURE  14  ROME  ROCKET  GROUND  TRACK 


The  track  on  the  Rome  Payload  covered  a  period  of  55  seconds  and 
consisted  of  only  one  segment  of  data.  Since  the  PltSD  software  was  ab¬ 
normally  terminated  while  the  Rome  Rocket  was  being  tracked,  the  system 
was  reloaded  and  restarted  with  the  result  that  the  mission  time  was  also 
restarted.  The  new  mission  time  for  the  start  of  the  Rome  Payload  track 
data  was  approximately  43  seconds.  The  ground  track  for  the  Rome  Payload 
is  shown  in  Figure  15.  The  average  range,  elevation,  and  azimuth  from 
HAPDAR  were  93,800  meters,  6°,  and  -12.5°,  respectively.  The  elevation 
relative  to  AMRAD  was  about  6.5°,  only  slightly  greater  than  the  elevation 
relative  to  HAPDAR.  At  this  elevation  angle  the  AMRAD  beam  is  beginning 
to  partially  pass  through  the  clutter  fence;  it  is  estimated  that,  for 
this  particular  geometry,  an  attenuation  of  about  0.75  dB  can  be  expected. 

B.  Handover  Calibration  Results 

The  test  plan  for  obtaining  relative  calibration  data  between  AMRAD 
and  HAPDAR  called  for  four  controlled  sphere  drops  from  an  aircraft.  The 
altitudes  and  locations  of  these  sphere  drops  were  designed  so  that  the 
measurements  would  cover  a  good  spread  in  azimuth,  elevation,  and  range. 
The  resulting  data  were  to  be  used  in  fitting  a  linear  model  of  relative 
R,  u,  and  v  bias  between  the  two  radars.  It  was  learned  during  the  w'eek 
of  8  January  1973  that  the  aircraft  scheduled  to  provide  these  sphere 
drops  was  no  longer  available,  with  the  result  that  the  calibration  test 
plan  could  not  be  carried  out.  Instead,  it  was  hoped  that  calibration 
data  would  be  obtained  on  various  balloon-launched  spheres  and  other 
targets  of  opportunity. 

Some  data  useful  for  first  order  calibration  were  obtained  from  the 
track  data  of  Sphere  One,  Rome  Sphere,  Rome  Rocket,  and  Rome  Payload. 

The  data  obtained  on  Sphere  One  indicated  an  average  range  difference  be¬ 
tween  AMRAD  and  HAPDAR  of  23  meters.  The  range  measured  by  AMRAD  (trans¬ 
formed  to  HAPDAR  coordinates)  was  consistently  greater  than  the  HAPDAR 
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FIGURE  15  ROME  PAYLOAD  GROUND  TRACK 


difference  of  2.6 


measurements.  In  addition,  there  was  an  average  u 
millisines  and  an  average  v  difference  of  -1.8  millisines. 


Comparing  the  biases  in  R,  u,  and  v  described  above  to  the  range 
gate  and  beamwidth  of  HAPDAR  indicates  that  the  range  bias  is  about  38 
percent  of  half  the  range  gate  width,  the  u  bias  is  about  18  percent  of 
half  the  beamwidth,  and  the  v  bias  is  about  12  percent  of  half  the 

beamwidth. 


Since  the  data  indicated  that  the  range  bias  was  the  most  crucial 

trv  nnrrect  all  HAPDAR  measure- 
to  the  handover  experiments,  it  was  decided  to  correct  an 

ments  lor  all  operations  subsequent  to  2  February  1973. 


The  angle  bias  terms  were  not  Included  in  the  HAPDAR  measurement 
corrections  at  this  time  for  several  reasons.  First,  they  were  not  very 
crucial  to  the  success  of  the  handover  experiment.  Second,  they  were 
obtained  at  an  azimuth  angle  far  removed  from  the  Athena  mission  azimuth 
(about  -20")  and  previous  experience  indicated  that  the  angle  biases  ap 
peared  to  be  functions  of  the  angles  themselves. 


The  remaining  data  useful  for  calibration  consist  of  the  data  on  the 
Rome  mission  tracks.  Due  to  the  fact  that  these  data  were  the  last  data 
to  be  obtained  on  the  radar  netting  program,  most  of  the  reason  for  the 
handover  calibration  had  vanished.  However,  since  the  SRI  handover  soft¬ 
ware  may  be  used  at  HAPDAR  for  some  additional  experiments,  the  data  were 

analyzed  for  range  bias. 


The  range  biases  for  the  Rome  Sphere,  Rome  Rocket,  and  Rome  Payload 
were  obtained  b,  averaging  the  difference  between  the  AMRAD  first  tracker 
range  estimate  and  the  corresponding  HAPDAR  track  range  estimate  taken 
at  one  second  intervals  fro.  the  available  data.  For  the  Rome  Rocket, 
nine  smoothed  points  were  used  which  covered  the  total  period  of  track 
data  available.  Twenty  points  and  30  points  were  used  from  the  data  on 
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the  Rome  Payload  and  Rome  Sphere,  respectively.  Although  these  numbers 
of  points  do  not  cover  the  entire  track  periods  for  these  two  tracks, 
the  averages  were  quite  stable  after  about  ten  points. 

The  result  of  the  bias  analysis  was  that  a  bias  of  0.4  meters  was 
obtained  from  the  Rome  Sphere  data,  19.2  meters  from  the  Rome  Payload 
data,  and  54.5  meters  from  the  Rome  Rocket  data.  These  three  sets  of 
data  were  taken  at  average  ranges  of  58,000  meters,  94,000  meters,  and 
170,000  meters,  respectively.  These  biases  were  such  that  AMRAD  measure¬ 
ments  were  greater  than  HAPDAR  measurements  for  each  case.  A  linear  fit 
to  these  biases  and  the  bias  numbers  themselves  are  shown  in  Figure  16. 
The  linear  fit  gives  a  bias  of  -28.5  meters  at  zero  range  and  a  slope  of 
0.000491  meters/meter.  Thus,  the  bias  is  zero  at  a  range  of  about  58,000 
meters.  As  can  be  seen  from  Figure  16,  the  three  points  fit  a  linear 
model  very  well.  It  should  be  noted  that  these  biases  were  obtained 
after  the  23-meter  bias  compensation  had  been  applied  to  all  HAPDAR 
measurements.  Thus,  any  range  bias  compensation  based  on  the  results 
shown  in  Figure  16  would  be  in  addition  to  the  previous  23-meter 
compensation. 

If  we  were  to  adjust  the  results  to  include  the  23-meter  compensa¬ 
tion,  we  would  have  to  add  23  meters  to  all  points,  and  we  would  obtain 
the  linear  bias  model  shown  in  Figure  17.  Note  that  this  linear  model 
has  a  small  zero  range  axis  intercept.  However,  if  we  add  the  Sphere 
One  bias  data,  as  we  have  done  in  Figure  17,  we  get  a  point  that  falls 
significantly  above  the  linear  model  and  suggests  a  piecewise  linear 
model.  Thus,  the  Sphere  One  bias  data  and  the  Rome  data  appear  to  be 
somewhat  inconsistent.  It  is  not  clear  at  this  time  what  phenomenon 
might  cause  this  type  of  result. 

The  linear  trend  suggests  at  first  hand  an  incorrect  velocity  of 
light,  or  a  slow  or  fast  clock  in  the  system.  However,  these  have  been 
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FIGURE  16  LINEAR  RANGE  BIAS  MODEL  BASED  ON  ROME-03  DATA 


checked  and  rechecked  and  appear  not  to  be  the  problem.  It  is  also  pos¬ 
sible  that  the  range  bias  might  be  affected  by  the  direction  of  the  beam, 
since  the  elevation  of  the  Rome  Rocket  data  was  different  from  the  eleva¬ 
tion  of  the  other  data  points.  However,  it  is  difficult  to  postulate 
such  a  mechanism.  Finally,  it  should  be  noted  that  the  Sphere  One  data 
and  the  Rome  data  were  obtained  approximately  20  days  apart,  a  time 
during  which  a  number  of  radar  hardware  changes  and  various  software 
modifications  were  made  to  the  system. 

The  bias  results  discussed  above  were  passed  on  to  the  RCA  people 
for  their  information,  and  TRANFT — which  processes  handed-over  AMRAD 
data — was  adjusted  so  that  the  linear  range  bias  corrections  shown  in 
Figure  16  will  be  applied  to  any  operation  of  the  handover  software  at 
HAPDAR  subsequent  to  16  March  1973. 

C.  Handover  Results 

The  data  from  the  Rome-03  mission  was  analyzed  to  assess  the  degree 
of  success  of  the  handover  experiment.  One  of  the  important  factors  in 
the  handover  experiment  is  the  handover  delay  time.  By  handover  delay 
time  we  mean  the  time  between  the  time  of  validity  of  the  handed  over 
AMRAD  state  and  the  time  when  the  first  handover  pulse  transmitted  by 
HAPDAR  reaches  the  handed  over  object.  For  the  Rome-03  mission,  handover 
delay  times  of  from  70  to  130  milliseconds  were  obtained.  Most  often, 
the  delay  was  only  70  ms.  The  variation  in  delay  is  a  function  of  the 
PHSD  scheduling  load  at  any  particular  time.  About  50  ms  of  the  delay 
time  is  used  in  passing  the  AMRAD  data  to  HAPDAR.  Thus,  we  see  that 
generally  only  20  ms  was  required  to  transmit  the  first  handover  pulse. 
This  indicates  that  handover  delays  were  within  acceptable  limits. 

The  data  obtained  on  the  handover  of  the  Rome  Sphere  are  tabulated 
in  Tables  3  and  4.  Table  3  contains  the  handover  data  for  the  first 
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Table  3 


AMRAD  FIRST  TRACKER  HANDOVER  DATA  FOR  ROME  SPHERE 


- r 

Attempt 

Number 

landover 

Time 

( seconds) 

Predicted 

SNR 

(dB) 

Time  oi 

1st  Hit 

(seconds) 

Measured 

SNR 

(dB) 

Range 

Error  on 

1st  Hit 

(meters) 

4 umber  o 

Misses 

Before 

1st  Hit 

1 

654. 96 

28 

655.01 

25.  3 

1.9 

0 

2 

656.96 

28.9 

657.03 

28.  3 

6.6 

0 

3 

658.96 

28 

659.03 

26.3 

3.8 

0 

4 

660. 96 

28 

661.03 

26.6 

-2.  1 

0 

5 

662. 96 

28 

663.03 

27.1 

1.7 

0 

6 

882.96 

28 

683.03 

24.7 

-0.9 

0 

7 

684, 96 

28.5 

685.03 

26.0 

-2.1 

0 

8 

686. 96 

28 

687.03 

27.1 

5.7 

0 

9 

688. 96 

29 

689.03 

25.7 

3.8 

0 

10 

690.96 

28 

691 . 03 

26.0 

2.6 

0 

11 

692. 96 

28.  5 

693.03 

27.4 

-1.9 

0 

12 

694. 96 

28 

695.01 

25.  8 

3.  5 

0 

13 

696. 96 

28 

697.03 

26.9 

-6.1 

0 

14 

698.96 

28 

699.03 

27.7 

5.9 

0 

15 

700.96 

28 

701.07 

24.9 

1.4 

1 

16 

702 . 96 

28.8 

703.03 

25.5 

-5.7 

0 

17 

704.96 

28.9 

705.03 

27.5 

3.3 

0 

18 

706.96 

28 

707.03 

26.3 

1.9 

0 

19 

708. 96 

28 

709.09 

24.7 

5.2 

1 

20 

710.96 

28 

711.03 

25.8 

-2.6 

0 

21 

712.96 

28.2 

713.03 

26.2 

0.003 

0 

22 

714.96 

28 

715.03 

26.3 

-2.8 

0 

23 

912.13 

28 

912.3 

25.5 

8.  5 

1 

24 

914. 13 

28.9 

914.  3 

24 

-5.4 

1 

26 

916. 13 

28 

916.22 

24.9 

0.24 

0 

26 

918. 13 

28.  5 

918.2 

25.  4 

4.3 

0 

27 

920. 13 

28 

920.3 

23.9 

-6.  9 

1 

28 

922. 13 

29 

922.3 

24 

3.3 

1 

29 

924.13 

29 

924.24 

26.5 

-2.  1 

0 

30 

926.13 

28 

926.24 

25.2 

-0.95 

0 

31 

928. 13 

28 

928.24 

24.7 

-3. 1 

0 

32 

930. 13 

28 

930.3 

23.6 

-4.3 

1 

33 

932. 13 

1  28. 9 

932.24 

26.4 

7.6 

0 

34 

934. 13 

30 

934.32 

24.8 

2.8 

2 

35 

936. 13 

28.2 

936.24 

26.3 

6.4 

0 

36 

938.  13 

28.  1 

938.24 

25.6 

-0.24 

0 

37 

940. 13 

28 

940.  2 

25.3 

3.3 

0 

38 

942. 13 

28 

942.24 

25.5 

2.6 

0 

1 


Table  1 


AMRAD  SECOND  TRACKER  HANDOVER  DATA  FOR  ROME  SPHERE 


Attempt 

Number 

Handover  P 

Time 

(seconds) 

1 

654.10 

2 

656. 10 

3 

658. 10 

4 

660.10 

5 

662. 10 

6 

664. 10 

7 

u84 . 09 

8 

686.09 

9 

688.09 

10 

690.09 

11 

692.10 

12 

694.10 

13 

696.10 

14 

698. 10 

15 

700. 10 

16 

702.10 

17 

704. 10 

18 

706. 10 

19 

708. 10 

20 

710. 10 

21 

712.09 

22 

714.09 

23 

913.07 

24 

915.07 

25 

917.07 

26 

919.07 

27 

921.07 

28 

923,07 

29 

925.07 

30 

927.07 

31 

929.07 

32 

931.07 

33 

933.07 

34 

935.07 

35 

937.07 

36 

939.07 

37 

941.07 

38 

943.07 

Time  of 
1st  Hit 
(seconds) 

654. 15 

656.27 

658.21 

660.21 

662.17 

664.21 

684.21 

686. 17 

688.21 

690. 17 

692.17 
694.23 
696.  23 
698. 19 

700.21 

702.21 

704.27 

706.21 

708.21 

710.27 


Range 

Measured  Error  on 
SNR  1st  Hit 

(dB)  (meters) 


Number  of 
Misses 
Before 
1st  Hit 


29.  8 

712.21 

29.5 

714.21 

30. 1 

913.20 

29.3 

915.14 

30 

917.20 

30 

919.20 

30.2 

921.20 

30 

923.20 

30 

925.20 

30 

927.20 

30 

929.20 

30 

931.22 

30 

933,24 

29.  8 

935.16 

30.2 

937.16 

30 

939.24 

29.  9 

941.22 

29.  9 

943, 16 

AMRAD  tracker,  and  Table  4  for  the  second  AMRAD  tracker.  The  following 
information  is  given  in  these  tables: 


(1)  Count  of  handover  attempts 

(2)  Time  of  handover  request  data 

(3)  Predicted  SNR  for  HAPDAR 

(4)  Time  of  first  hit  by  HAPDAR 

(5)  Measured  SNR  for  first  hit 

(6)  Measured  range  error  for  first  hit 

(7)  Number  of  misses  before  first  hit. 

Table  3  shows  that  38  handover  attempts  were  made  for  AMRAD ' s  first 
tracker.  Of  these  38  attempts,  30  hits  were  obtained  by  HAPDAR  on  the 
first  try,  seven  were  obtained  on  the  second  try,  and  one  required  three 
tries.  Table  4  shows  that  38  attempts  were  made  for  AMRAD ' s  second 
tracker;  of  these,  22  hits  were  obtained  on  the  first  try  while  the  re¬ 
maining  16  hits  required  a  second  attempt.  Taken  together,  we  see  that 
in  all  but  one  case,  a  hit  was  obtained  within  two  attempts.  In  that  re¬ 
maining  case,  one  additional  attempt  was  required.  These  results  are 
summarized  in  Table  5.  In  all  but  one  case,  a  solid  track  was  estab¬ 
lished  by  HAPDAR  subsequent  to  the  first  hit  after  handover.  The  one 
time  this  did  not  occur,  18  hits  and  11  misses  were  recorded  before  the 
next  handover  attempt. 

Although  these  statistics  are  quite  good,  a  higher  number  of  handover 
hits  on  the  first  attempt  were  expected  due  to  the  good  SNR.  However, 
the  lower  number  of  first  attempt  hits  can  be  explained  by  the  fact  that 
the  two  radars  have  not  as  yet  been  properly  calibrated  relative  to  each 
other  in  signal-to-noise  sensitivity.  Due  to  the  different  sensitivities 
of  the  two  radars,  the  SNR  seen  by  AMRAD  must  be  properly  adjusted  to 
obtain  a  good  estimate  of  the  SNR  that  HAPDAR  should  see.  This  is  cur¬ 
rently  done  by  subtracting  23  dB  from  the  AMRAD  measured  SNR  before 
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Table  5 


SUMMARY  OF  ROME  SPHERE  HANDOVERS 


Number  of 

Handovers 

Percentage  of 

Hits  on 

First  Pulse 

Percentage  of 
Hits  on  First 

or  Second  Pulse 

First  track 

38 

78.  9% 

97.  4% 

Second  track 

38 

57.  9 

100 

Both  tracks 

76 

68.  4 

98.  7 

handing  over  the  AMRAD  data  to  HAPDAR.  Should  the  SNR  seen  by  HAPDAR  be 
consistently  lower  than  predicted  by  AMRAD  at  the  time  of  handover,  the 
AGC.  setting  for  the  first  HAPDAR  track  pulse  will  be  set  consistently 
too  low  so  that  the  probability  of  missing  a  return  increases.  The  proba¬ 
bility  of  missing  a  return  will  be  greater  as  the  difference  between  the 
SNRs  becomes  greater.  When  a  miss  is  obtained  on  the  first  try,  the  AGC 
is  increased  by  steps  of  3  dB  for  subsequent  track  pulses.  Thus,  one 
might  expect  that  if  the  predicted  SNR  was  generally  too  high,  there 
might  be  a  significant  number  of  misses  on  first  attempts,  and  a  very 
small  number  of  misses  on  second  attempts. 

To  determine  whether  this  occurred  for  the  Rome  Sphere  track,  the 
handover  data  were  separated  into  two  groups.  The  first  group  consisted 
of  data  where  the  difference  between  the  AMRAD  predicted  SNR  and  the 
HAPDAR  measured  SNR  was  less  than  4  dB.  The  second  group  consisted  of 
data  where  the  difference  was  greater  than  4  dB.  (The  largest  difference 
obtained  was  7.1  dB,  and  the  predicted  difference  was  always  greater  than 
the  measured  difference.)  The  resulting  summaries  of  handover  for  each 
group  are  shown  in  Table  6.  From  this  table  we  see  a  dramatic  improve¬ 
ment  for  the  first  group,  and  very  poor  performance  for  the  second  group. 
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Table  6 


SUBSET  SUMMARIES  OF  ROME  SPHERE  HANDOVERS 


Number  of  Hits  j 
on  First  Pulse 

Number  of  Hits 

on  Second  Pulse 

Number  of  Hits 

on  Third  Pulse 

SNR  difference  less 

than  4  dB 

First  track 

30 

3 

0 

Second  track 

14 

0 

0 

Both 

44 

3 

0 

SNR  difference 

greater  than  4  dB 

First  track 

0 

4 

1 

Second  track 

8 

16 

0 

Both 

8 

20 

1 

Or,  stated  another  way,  we  see  that  87.5  percent  of  the  misses  on  the 
first  attempt  occurred  when  the  difference  between  the  predicted  and 
measured  SNR  was  greater  than  4  dB. 

Thus  the  data  seem  to  indicate  very  good  first  pulse  handover  per¬ 
formance  in  light  of  the  state  of  calibration  between  AMRAD  and  HAPDAR. 
The  data  suggest  that  the  SNR  adjustment  of  the  AMRAD  measurements 
handed  over  to  HAPDAR  be  increased  by  about  3  dB— from  23  dB  to  26  dB. 

The  data  obtained  on  the  handover  of  the  Rome  Payload  are  tabulated 
in  Tables  7  and  8  for  the  first  and  the  second  AMRAD  trackers,  respec¬ 
tively.  The  data  in  these  tables  indicate  a  fairly  good  performance  of 
handover  in  terms  of  first  hits.  However,  these  data  are  not  considered 
very  reliable  because  the  elevation  angle  was  quite  low  (about  6  )  and 
the  radar  target  was  at  a  range  that  is  in  the  region  of  high  clutter. 
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Table  7 


AMRAD  FIRST  TRACKER  HANDOVER  DATA  FOR  ROME  PAYLOAD 


Attempt 

Number 

Handover 

Time 

(seconds) 

Predicted 

SNR 

(dB) 

Time  of 

1st  Hit 

(seconds) 

Measured 

SNR 

(dB) 

Range 

Error  on 

1st  Hit 

(meters) 

Number  of 

Misses 

Before 

1st  Hit 

1 

43.40 

23.2 

43.45 

20.4 

-19.6 

0 

2 

45.40 

17.8 

45.55 

17.1 

-25.8 

1 

3 

47.40 

12.2 

47.49 

17.3 

-30.3 

0 

4 

49.40 

15.3 

49.49 

20.9 

-23.4 

0 

5 

51.40 

18.  5 

51.49 

26.3 

-22.9 

0 

6 

53.40 

15 

53.49 

25.2 

-16.3 

o 

7 

55.40 

— 

* 

♦ 

* 

* 

8 

57.62 

<  10 

57.72 

19.3 

-5.9 

0 

9 

59.62 

<  10 

59.78 

11.9 

-6.2 

1 

10 

61.62 

11.9 

61.70 

19.  5 

-30.3 

0 

11 

63.62 

15.3 

63.72 

25.3 

-12. 1 

0 

12 

65.72 

12.9 

66.12 

8.4 

13.2 

5 

13 

67.62 

14.6 

67.78 

6 

-13 

1 

14 

69.62 

14.3 

69.74 

16.4 

-21 

0 

15 

— 

18.5 

74.29 

— 

29.  9 

1 

16 

76.  lx 

12.5 

76.  15 

18.7 

1.63 

0 

17 

78. 11 

13.6 

— 

— 

— 

0 

18 

— 

80.31 

20.6 

-28.6 

0 

19 

— 

— 

82.91 

13 

-29.6 

2 

20 

84.52 

<  10 

84.63 

17.9 

-30.2 

0 

21 

86.62 

<  10 

86.69 

26.6 

-29.  1 

0 

22 

88.62 

<  10 

88.67 

15.2 

-11.6 

0 

23 

90.62 

<  10 

90.69 

18.  5 

-8.3 

0 

24 

92.62 

<  10 

92.67 

21.4 

3.8 

0 

25 

94.72 

<  10 

94.84 

20.9 

-13.5 

1 

26 

96.72 

<  10 

96.78 

25 

-21 

0 

27 

98.81 

<  10 

— 

99.08 

23.3 

-13.5 

J _ 

1 

* 

No  hits. 
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Table  8 


AMRAD  SECOND  TRACKER  HANDOVER  DATA  FOR  ROME  PAYLOAD 


Attempt 

Number 

Handover 

Time 

(seconds) 

Predicted 

SNR 

(dB) 

Time  of 

1st  Hit 

( seconds) 

Measured 

SNR 

(dB) 

Range 

Error  on 

1st  Hit 

(meters) 

Number  of 

Misses 

Before 

1st  Hit 

1 

44.  44 

<  10 

44.  51 

16.8 

30 

0 

2 

46 . 44 

18.  4 

46.63 

15.  3 

15.  2 

1 

3 

48 . 44 

21.3 

48.73 

16.  1 

30.2 

3 

4 

50.44 

16.6 

50.  53 

19.  5 

15. 3 

0 

5 

52.44 

19.8 

52.57 

17 

30.2 

0 

6 

54. 56 

17.2 

54.67 

15.  5 

30.  2 

0 

7 

56. 56 

— 

* 

* 

* 

* 

8 

58.  85 

17.9 

— 

— 

— 

0 

9 

60.85 

13.  4 

60.94 

22.6 

-29.  7 

0 

10 

62.85 

13.6 

62.94 

12.7 

30.  2 

0 

11 

64.85 

10.3 

64. 93 

15.7 

15.2 

0 

12 

66.85 

11.8 

66.98 

16 

-59.8 

0 

13 

71.05 

13.9 

— 

— 

— 

1 

14 

— 

— 

— 

— 

— 

0 

15 

75.25 

13.8 

75.33 

13.5 

30.2 

0 

16 

77.  15 

12.3 

— 

— 

— 

1 

17 

— 

— 

— 

-- 

— 

0 

18 

81. 25 

<  10 

81. 53 

20.  9 

-89.8 

1 

19 

83.34 

<  10 

83.49 

13.  3 

-18 

0 

20 

85.44 

<  10 

85.83 

1.36 

-21 

4 

21 

87.34 

<  10 

87.47 

11. 9 

30.  2 

0 

22 

89.  34 

<  10 

89.  43 

14.9 

30.2 

0 

23 

91.34 

<  10 

91.43 

15.  5 

30.2 

0 

24 

93.  34 

<  10 

93.43 

10.6 

45.2 

0 

25 

95.34 

<  10 

95.  5 

21.4 

0.09 

1 

26 

— 

— 

97.  48 

18.  2 

15.2 

0 

* 

No  hits. 
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This  raises  the  possibility  of  obtaining  an  excessive  number  of  hits  from 
clutter  rather  than  from  any  real  target.  This  type  of  situation  is  sug¬ 
gested  by  the  fact  that  during  this  period  of  operation  many  tracks  were 
initiated  and  then  purged.  None  of  these  independent  tracks  (i.e.,  non- 
dedicated  tracks)  and  only  a  few  handed-over  tracks  were  ever  solidly 
established.  In  addition,  the  AMRAD  predicted  SNRs  do  not  appear  to  cor¬ 
relate  very  well  with  the  measured  SNRs,  as  can  be  seen  from  Tables  7  and 
8.  On  the  other  hand,  for  the  Rome  Sphere  data,  the  SNRs  (though  somewhat 
biased)  correlated  fairly  well.  In  general,  AMRAD  was  predicting  a 
smaller  SNR  for  the  Rome  Payload  than  was  measured,  which  is  opposite  to 
the  trend  on  the  Rome  Sphere.  In  particular,  toward  the  end  of  the  track, 
AMRAD  was  consistently  predicting  SNRs  of  less  than  10  dB  while  SNRs  sig¬ 
nificantly  greater  than  10  dB  were  being  measured  by  HAPDAR. 

The  conclusion  appears  to  be  that  little  can  be  said  about  the  per¬ 
formance  of  handover  on  the  Rome  Payload  because  of  the  apparent  high 
clutter  effects. 

The  data  obtained  on  the  handover  of  the  Rome  Rocket  are  tabulated 
in  Tables  9  and  10  for  the  first  and  second  AMRAD  trackers,  respectively. 
Also  tabulated  in  each  of  these  tables  are  the  number  of  hits  and  misses 
for  each  of  the  handed-over  tracks,  ,iust  prior  to  the  next  handover  at¬ 
tempts.  These  data  indicate  that  the  second  AMRAD  track  was  never  handed 
over  successfully,  while  only  partial  success  was  achieved  on  the  first 
AMRAD  track  handovers.  This  is  consistent  with  the  low  SNR  indicated 
by  AMRAD  on  the  second  track. 

The  SNRs  indicated  by  AMRAD  on  the  first  track  are  considered  mar¬ 
ginal  in  view  of  the  fact  that  the  ROS  can  be  expected  to  fluctuate.  The 
total  number  of  hits  and  misses  indicated  by  the  handed-over  track  on  the 
first  target  appears  to  be  consistent  with  the  SNRs.  ..  t  is  interesting 
to  note  that — just  as  for  the  Rome  Sphere  data — the  number  of  attempts 
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required  for  the  first  hit  by  HAPDAR  on  a  handed-over  track  is  correlated 
with  the  difference  between  the  AMRAD  predicted  SNR  and  the  measured  SNR. 

The  general  conclusion  on  the  Rome  Rocket  handover  data  is  that  the 
SNR  for  the  second  target  tracked  by  AMRAD  was  too  low  for  any  success  at 
handover,  and  the  handovers  on  the  first  target  wore  partially  successful 
(i.e.,  only  two  out  of  five  attempts  resulted  in  solid  handed-over  tracks) 
due  to  a  marginal  SNR. 

D .  Correlation  Results 

The  track  data  obtained  from  the  Rome  Sphere  provided  a  fairly  good 
test  of  the  correlation  algorithm.  During  this  part  of  the  Rome  mission 
HAPDAR  had  three  active  tracks,  as  expected:  the  two  dedicated  handover 
track  channels  and  an  independent  track  of  the  sphere.  The  correlation 
algorithm  is  concerned  with  how  each  of  the  two  AMRAD  tracks  correlate 
with  the  independent  HAPDAR  track.  Since  both  AMRAD  trackers  were  on  the 
same  sphere,  we  would  expect  that  both  AMRAD  tracks  would  correlate  with 
the  independent  HAPDAR  track.  Fortuitously,  in  view  of  the  meager  cor¬ 
relation  data  obtained  to  date,  this  was  not  the  case.  It  turned  out 
that  there  was  a  range  bias  between  the  two  AMRAD  trackers  on  the  order 
of  7.5  meters  (the  first  tracker  was  always  greater  than  the  second). 

Thus,  although  only  one  object  was  tracked,  two  tracks  were  obtained 
which  in  effect  correspond  to  two  spheres  with  a  constant  separation  of 
about  7.5  meters.  The  relative  range  bias  between  AMRAD  and  HAPDAR  as 
obtained  by  comparing  the  AMRAD  first  tracker  data  to  the  HAPDAR  data 
was  only  about  0.4  meters.  Thus,  the  two  radars  were  fairly  well  cali¬ 
brated  in  range  for  the  Rome  Sphere  tracks. 

The  two  AMRAD  tracks  are  based  on  independent  range  measurements 
but  completely  correlated  angle  measurements.  Thus,  the  resulting  cor¬ 
relation  parameters  computed  by  QUECOR  for  each  AMRAD  track  paired  with 
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the  HAPDAR  track  are  partially  correlated  with  each  other.  As  we  shall 

see,  the  independent  range  measurements  have  the  dominant  effect  on  the 

* 

computed  Q's  (i.e.  the  correlation  parameters  ). 

The  Q's  were  computed  once  every  second  (once  every  two  seconds  for 
each  AMRAD  track).  Each  Q  computation  provides  a  separate  correlation 
trial.  The  Q's  obtained  for  the  first  two  segments  of  the  Rome  Sphere 
track  are  plotted  as  a  function  of  mission  time  in  Figure  18,  and  those 
for  the  third  and  final  segment  are  shown  in  Figure  19.  From  Figure  18 
we  see  that  the  Q’s  for  the  first  AMRAD  track  and  independent  HAPDAR 
track  pair  range  from  about  0.7  to  12.  On  the  other  hand,  the  Q's  for 
the  second  AMRAD  track  and  independent  HAPDAR  track  pair  range  from  2.6 
to  82.  From  Figure  19  we  see  that  the  Q's  for  the  first  pair  of  tracks 
range  from  0.4  to  40  while  those  for  the  second  pair  range  from  6  to  143 
Although  these  results  indicate  a  good  degree  of  overlap,  the  frequency 
cf  overlap  is  low.  We  see  this  by  considering  the  frequency  of  exceed¬ 
ances  of  some  threshold  by  the  first  track  pair  Q's,  and  the  frequency 
of  nonexceedances  of  the  same  threshold  by  the  second  track  pair  Q's. 

If  we  consider  a  threshold  of  13.0,  we  see  that  over  all  three  segments 
of  data  (Figures  18  and  19)  we  have  10.3  percent  exceedances  for  the 
first  track  pair  Q's,  and  11.1  percent  nonexceedances  for  the  second 
track  pair  Q's.  In  the  context  of  making  correlation  decisions,  the  re¬ 
sults  indicate  that  with  a  correlation  decision  threshold  of  13  and  an 
object  separation  of  only  7.5  meters,  the  correct  decision  as  to  whether 
the  tracked  objects  were  the  same  or  not  would  have  been  made  a  total  of 
67  out  of  75  times  or  about  89  percent  of  the  time.  Four  out  of  the 
eight  erroneous  decisions  would  have  been  made  in  designating  two 
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FIGURE  19  ROME  SPHERE  CORRELATION  DATA,  PART  II 
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correlated  tracks  as  uncorrelated,  and  the  remaining  four  erroneous  de¬ 
cisions  would  have  been  made  in  designating  two  uncorrelated  tracks  as 
correlated. 

The  average  value  of  the  first  track  pair  Q's  was  about  7.1,  while 
the  average  for  the  second  track  pair  was  about  33.7.  In  a  bias  free 
situation  we  would  expect  the  average  value  for  the  first  track  pair  of 
Q's  to  be  3.0.  In  general,  much  better  correlation  results  were  obtained 
in  the  first  two  segments  of  the  Rome  Sphere  data.  These  data  show 
average  Q's  of  about  4  and  26.  Thus,  the  expected  average  Q  for  the 
first  track  pair  was  almost  achieved  with  the  earlier  data. 

These  results  indicate  a  very  good  performance  of  the  correlation 
algorithm  in  view  of  (1)  the  fact  that  angle  biases  have  not  yet  been 
calibrated  out  and  (2)  the  small  separation  (i.e.,  the  range  bias  between 
the  AMRAD  trackers)  of  7.5  meters  between  the  two  AMRAD  tracks.  Such  a 
small  separation  in  the  case  where  there  are  two  real  objects  would  not 
even  result  in  two  separate  tracks,  since  the  objects  would  not  be  re¬ 
solved  (AMRAD  has  a  range  resolution  of  about  12  meters).  In  any  realistic 
case,  the  Q's  corresponding  to  the  uncorrelated  objects  will  be  much 
greater  than  those  obtained  from  the  Rome  Sphere  tracks,  and  a  slightly 
higher  decision  threshold  would  have  resulted  in  almost  no  incorrect  coi- 
relation  decisions.  This  last  conclusion  is  supported  by  the  correlation 
results  on  the  Rome  Rocket  track  data,  where  there  were  actually  two  real 
objects  for  AMRAD  to  track.  These  results  are  discussed  next. 

No  correlation  results  in  the  sense  of  correlation  of  tracks  from  one 
radar  with  independent  tracks  from  a  second  radar  were  obtained  for  the 
Rome  Payload  or  the  Rome  Rocket,  since  no  independent  tracks  were  ever 
established  by  HAPDAR  during  those  periods  of  operation.  As  discussed  in 
the  section  on  handover  results  this  was  probably  due  to  high  clutter  in 
the  case  of  the  Rome  Payload,  and  low  SNR  coupled  with  the  fact  that  the 


66 


system  abnormally  terminated  a  short  time  after  initiation  of  the  handover 
experiment  in  the  case  of  the  Rome  Rocket. 

However,  some  results  related  to  correlation  are  available  because 
all  HAPDAR  tracks,  including  the  two  dedicated  HAPDAR  tracks,  are  pro¬ 
cessed  through  QUECOR  approximately  once  every  second.  These  dedicated 
HAPDAR  tracks  are  not  independent  of  the  AMRAD  tracks  since  they  are  re¬ 
initialized  with  the  AMRAD  track  data  once  every  two  seconds  for  dedi¬ 
cated  track.  These  dedicated  tracks  are  never  purged  even  though  no  hits 
are  ever  obtained.  Thus,  just  after  they  are  reinitialized,  or  if  time 
passes  without  any  hits  by  HAPDAR,  they  should  be  highly  correlated  with 
the  AMF-AD  tracks.  However,  after  a  number  of  hits  are  obtained  they  are 
essentially  independent  of  the  AMRAD  tracks.  The  number  of  hits  required 
for  the  validity  of  this  last  statement  is  not  known  precisely,  but  is 
believed  to  be  on  the  order  of  ten  hits. 

The  unique  feature  of  the  Rome  Rocket  data  is  that  two  real  targets 
were  tracked  by  AMRAD,  and  one  of  them  was  handed  over  with  partial  suc¬ 
cess.  The  first  AMRAD  track  had  a  higher  SNR  than  the  second  and  was 
apparently  the  booster  of  the  Rome  Rocket;  the  second  AMRAD  track  then 
corresponds  to  the  ejected  instrument  package  payload  for  the  Rome  mis¬ 
sion.  The  separation  between  these  two  objects  was  approximately  600 
meters.  This  separation  is  typical  of  the  separation  that  might  be  en¬ 
countered  in  a  tactical  situation.  At  such  separations,  we  would  expect 
quite  large  values  of  Q  when  we  attempt  to  correlate  the  two  separate 
objects.  The  values  of  the  Q's  corresponding  to  the  attempts  at  corre¬ 
lation  of  each  of  the  AMRAD  tracks  with  the  first  dedicated  track  at 
HAPDAR  are  tabulated  in  Table  11. 

The  numbers  in  Table  11  indicate  a  range  of  Q's  of  from  about  5  to 
38  for  the  pair  corresponding  to  the  first  AMRAD  track.  On  the  other 
hand,  a  range  of  Q's  of  from  about  2000  to  8500  was  obtained  for  the 


67 


Table  11 


CORRELATION  DATA  FOR  ROME  ROCKET 


Correlation 

Time 

(seconds) 

Hits/Misses 
for  SRI-1* 

Q  Value  for  AM-1 
Compared  with  SRI-1 

Q  Value  for  AM-2 
Compared  with  SRI-1 

2821. 53 

7/0 

2500 

2822. 98 

24/4 

37.9 

2823. 53 

4/3 

2480 

2824. 98 

21/8 

19.6 

2825. 53 

4/3 

8440 

2826.98 

10/18 

5. 14 

2827. 53 

5/2 

1980 

2828. 98 

19/10 

15.9 

2829.53 

6/1 

2530 

*SRI -1  is  used  to  designate  the  first  HAPDAR  dedicated  track,  AM-1 
designates  the  first  AMRAD  track,  and  AM-2  designates  the  second 
AMRAD  track. 


pair  corresponding  to  the  second  AMRAD  track.  The  higher  than  expected 
Q's  for  the  first  AMRAD  track  is  due  to  the  fairly  large  bias  in  range 
between  the  two  radars.  However,  the  very  large  Q's  for  the  uncorre¬ 
lated  tracks  (i.e.,  the  second  AMRAD  track  and  the  first  dedicated 
HAPDAR  track)  are  primarily  due  to  the  600-meter  separation  between  the 
two  real  objects. 

As  indicated  in  Table  11,  by  the  hit  and  miss  count,  QUECOR  was  con¬ 
sistently  executed  for  the  second  AMRAD  track  too  soon  after  the  first 
AMRAD  track.  Thus,  because  of  .the  relatively  small  number  of  hits  we 
cannot  say  that  the  first  dedicated  HAPDAR  track  is  independent  of  the 
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first  AMRAD  track.  However,  this  does  not  mean  that  the  magnitudes  of 
the  Q's  obtained  would  be  much  different.  It  does  mean  that  we  would 
not  see  the  proper  statistical  variation  of  the  Q’s  over  a  large  number 
of  such  trials. 

Thus,  we  can  expect  that  with  separations  of  several  hundreds  of 
meters  between  objects,  large  separations  in  the  magnitudes  of  the  com¬ 
puted  correlation  parameters  will  result  and  will  allow  proper  correla¬ 
tion  decisions  with  a  high  degree  of  success. 
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Appendix  A 


HANDOVER  PROGRAM  AMTOHAP 

A.  Objective  of  Handover  Program 

The  purpose  of  the  program  AMTOHAP  is  to  take  data  gathered  by  the 
primary  and  secondary  AMRAD  trackers  and  hand  the  data  over  to  the  HAPDAR 
computer  via  the  MILGO  interface  and  kineplex  modems.  In  the  program's 
operating  mode,  AMRAD  data  come  directly  from  the  AMRAD  radar  to  the  SDS 
920  computer;  in  the  test  mode,  AMRAD 's  Sigma  5  computer  generates  a 
vehicle  trajectory  and,  simulating  the  radar,  sends  this  data  to  the  SDS 
920  computer.  (The  AMRAD-to-HAPDAR  coordinate  conversion  and  vehicle- 
trajectory  smoothing  are  now  performed  at  HAPDAR's  IBM  360/65  computer.) 
The  coordinate  handover  is  accomplished  in  two  steps:  the  first  target 
and  its  AGC  setting  are  handed  over  following  reception  of  a  predict 
interrupt  from  the  MILGO  interface,  and  the  second  target  is  handed  over 
following  reception  of  a  sync  interrupt  from  the  MILGO  interface.  To 
allow  for  post-mission  analysis  of  the  handover  operation,  all  pertinent 
AMRAD  and  HAPDAR  data  are  recorded  on  magnetic  tape  at  ten-second  inter¬ 
vals  by  the  program  AMTOHAP. 

B.  Description  of  Program  AMTOHAP 

The  program  AMTOHAP  is  an  interrupt-driven  algorithm  that  provides 
the  software  connection  between  the  AMRAD  and  HAPDAR  radars.  Its  his¬ 
torical  development,  mathematical  structure,  logical  structure,  interrupt 
structure,  and  operating  modes  are  outlined  in  turn\below.  A  listing  of 
the  program  AMTOHAP  will  be  found  at  the  end  of  this  appendix. 
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1. 


Historical  Developments 


The  program  AMTOHAP  was  originally  developed  under  the  previous 
contract  at  SRI  on  the  Institute's  CDC  6400  computer.  Several  versions 
were  originated  and  tested  against  AMRAD  Athena  data  to  determine  CPU 
demands,  memory  requirements,  and  tracking  capability.  These  included 
a  Kalman  filter  algorithm,  a  least-square  processor,  and  a  Type-II  filter. 
The  Kalman  filter  algorithm  was  found  to  consume  both  excessive  CPU  time 
and  excessive  main  storage,  as  well  as  suffering  instability  when  proces¬ 
sing  real  radar  data.  The  least-squares  algorithm  on  the  other  hand, 
although  requiring  considerably  less  CPU  and  storage,  still  promised  to 
overburden  AMRAD’s  SDS  920.  Experimentation  with  the  Type-II  filter 
indicated  that  its  CPU  and  memory  requirements  were  tolerable,  and  that 
it  remained  stable  under  all  tracking  conditions.  Accordingly,  this 
filtering  algorithm  was  selected  for  use  in  the  field  demonstrations  at 
WSMR. 

The  initial  versions  of  AMTOHAP  were  written  in  FORTRAN  II, 
since  no  bit  manipulations  or  interrupt  handling  were  required  during 
the  algorithm  evaluation  studies  described  above.  However,  following 
selection  of  the  Type-II  filter,  efforts  were  made  to  compress  the  CDC 
6400 'program  and  make  it  run  on  SRI's  SDS  930  computer.  In  paiticular, 
efforts  were  made  to  replace  the  standard  FORTRAN  floating-point  sine 
and  cosine  routines  with  specially  coded  fixed-point  assembly-language 
algorithms.  By  means  of  these  algorithms  the  speed  of  trigonometric 
calculations  was  increased  by  approximately  an  order  of  magnitude.  In 
addition,  the  FORTRAN  magnetic  tape  read  and  write  routines  were  replaced 
with  assembly-language  algorithms  operating  in  an  interlaced  mode.  That 
is,  the  tape  read  and  write  functions  were  able  to  proceed  in  parallel 
with  other  CPU  operations. 
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Additional  assembly- language  efforts  were  made  to  (1)  check 
the  operating  mode  of  the  program,  (2)  idle  the  program  in  anticipation 
of  I/O  interrupts,  (3)  handle  the  actual  I/O  interrupts,  (4)  input  AMRAD 
radar  measurements,  (5)  output  HAPDAR  position  and  velocity  estimates, 

(6)  strip  bits  from  inputted  data  words,  and  (7)  pack  bits  for  outputted 
data  words.  These  procedures  were  initially  written  at  SRI  and  subjected 
to  a  preliminary  debugging  on  SRI's  SDS  930.  The  software  was  then 
transported  to  WSMR  and  given  a  final  debugging  on  AMRAD’ s  SDS  920. 

Finally,  additional  efforts  were  made  to  speed  the  execution  of  the  pro¬ 
gram  by  eliminating  redundant  calculations  and  unnecessary  indexing 
operat ions . 

To  adapt  AMTOHAP  for  the  present  contract  work,  the  coordinate 
conversion,  prediction,  and  conversion  routines  were  removed  from  the 
program.  (These  routines  later  became  part  of  the  program  TRANFT . )  In 
addition  the  program  was  altered  to  accept  both  primary  and  secondary 
target  coordinates  from  AMRAD  and  to  transmit  them  to  HAPDAR.  Also,  a 
routine  was  added  to  automatically  modify  the  SNR  level  transmitted  to 
HAPDAR  when  the  AMRAD  receiver  parametric  amplifiers  were  turned  off  on 
strong  targets. 

2.  Mathematical  Structure 

Because  the  coordinate  conversion,  prediction,  and  correction 
routines  were  deleted  from  AMTOHAP,  the  mathematical  structure  of  the 
routine  degenerated  to  scaling  the  SNR  for  handover  to  HAPDAR.  All  re¬ 
maining  mathematical  operations  consisted  of  (1)  data  collection,  storage, 
and  retrieval,  (2)  bit  manipulation,  (3)  and  logical  checking. 
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c. 


AMTOHAP  Flowchart 


To  speed  processing,  the  program  AMTOHAP  was  designed  using  in-line, 
rather  than  modular,  code.  Figure  A-l  shows  the  basic  layout  and  flow 
of  the  algorithm.  The  program  is  first  initialized  (constants  defined 
and  flags  set)  and  then  put  into  an  idle  loop  (described  below).  On 
receiving  an  interrupt,  the  computer  leaves  the  idle  loop  and  checks  to 
see  if  the  second  target  coordinates  should  be  sent  to  HAPDAR.  Following 
this  operation,  the  computer  checks  to  see  if  a  new  predictor-corrector 
cycle  should  be  initiated.  If  so — that  is,  if  flag  LFLG  or  MFLG  is 
zero — the  program  reads  in  the  latest  AMRAD  measurement.  The  algorithm 
then  outputs  the  collected  data  to  HAPDAR,  and  returns  to  the  idle  loop. 

Every  fiftieth  input-output  cycle,  the  program  AMTOHAP  writes  the 
collected  data  on  magnetic  tape — unless  Breakpoint  Switch  Three  has  been 
thrown  on  the  computer  console — for  post-mission  analysis.  The  program 
next  checks  to  see  if  the  mission  is  completed,  and  if  so  (that  is,  if 
I STD  =  0)  the  program  rewinds  the  magnetic  tape  and  dumps  its  contents 
on  the  line  printer.  Next,  the  program  interrogates  the  teletypewriter 
for  the  constant  IGO.  This  constant  tells  the  computer  whether  or  not 
to  terminate  the  program  AMTOHAP;  that  is,  IGO  =  0  means  end  the  pro¬ 
cessing  and  IGO  ^  0  means  return  to  the  beginning  of  the  program.  In 
the  latter  case,  the  magnetic  tape  is  rewound  and  the  program  reinitial¬ 
ized.  In  particular,  the  contents  of  the  magnetic  tape  are  destroyed. 

1 .  Interrupt  Structure 

Owing  to  the  presence  of  five  interrupts  of  varying  priority 
level,  some  sophistication  was  required  to  ensure  that  the  timing  and 
control  functions  were  properly  handled  in  AMTOHAP.  During  normal  opera¬ 
tion  the  program  settles  into  a  continuous  loop  in  the  subroutine  IDLE 
after  completing  all  required  tasks.  As  shown  in  Figure  A-2,  the  loop 
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action  depends  on  the  positive  value  of  the  interrupt  flag  IFLG.  When 


an  external  interrupt  appears,  the  computer  stops  its  present  task  and 
executes  the  interrupt  service  routine  corresponding  to  that  interrupt: 


that  is,  SER30,  SER31,  SER32,  SER33,  or  SER200.  The  service  routines 


SER31  and  SER33  serve  to  clear  the  interrupts  associated  with  the  tape 


write  and  read  routines,  while  the  remaining  three  service  routines  con¬ 
trol  the  overall  handover  procedure.  Figures  A-3,  A-4,  and  A-5  show 


flow  diagrams  for  the  various  interrupts. 


When  an  external  interrupt  causes  SER30,  SER32,  or  SER200  to 


be  executed,  the  interrupt  flag  IFLG  is  immediately  set  equal  to  -1  by 
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FIGURE  A-3  AMRAD  MAIN  BANG  INTERRUPT  (SER30) 


FIGURE  A-5  VELOCITY  SYNC  INTERRUPT  (SER32) 


the  executed  routine.  Accordingly,  on  return  the  computer  will  immediately 
jump  out  of  the  IDLE  loop  and  go  back  to  the  main  program.  If  the  second 
target  output  flag,  KFLG,  has  been  zeroed  by  a  SER30  increment,  then  the 
program  will  immediately  output  second  target  data  to  HAPDAR  via  the 
assembly- language  subroutine  VOUT  (see  Figure  A-l).  The  computer  next 
checks  to  see  if  one  of  the  data- input  flags,  LFLG  or  MFLG,  has  been 
zeroed  by  a  SERGO  increment;  if  so,  new  data  is  immediately  read  in  from 
the  HAPDAR  radar,  and  the  resulting  position  data  outputted  to  the  HAPDAR 
radar  by  the  subroutine  POUT.  A  position-out  flag,  JFLG,  was  originally 

intended  to  schedule  the  output  time  for  the  position  coordinates,  but 

/ 

this  option  was  not  used  for  the  field  experiments. 

The  kineplex  predict  and  AMRAD  main  bang  interrupts  occur 
simultaneously."  However,  because  slight  timing  delays  always  develop 
in  electronic  circuitry,  one  interrupt  will  tend  to  arrive  before  the 
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other ,  and  the  order  of  execution  of  SER32  and  SER200  will  remain  un¬ 
predictable.  Since  SER200  reinitializes  the  interrupt  system  and  SER32 
increments  it,  these  routines  must  be  executed  in  proper  order  to  ensure 
correct  timing  on  the  handover  message.  This  ordering  problem  is  solved 
in  AMTOHAP  by  using  the  higher  priority  assigned  to  SER32.  Thus,  if  the 
AMRAD  main  bang  interrupt  arrives  first,  SER200  will  be  executed  after 
SER32,  and  the  initialization  process  follows  the  incrementing  operation. 
On  the  other  hand,  when  the  kineplex  sync  interrupt  arrives  first,  the 
execution  of  SER200  will  begin,  but  then  be  interrupted  almost  immediately 
by  the  AMRAD  main  bang  interrupt.  Because  of  priorities,  the  computer 
will  drop  SER200  and  begin  executing  SER32  instead.  On  completing  SER32, 
it  will  return  again  to  SER200  and  complete  its  execution.  In  other 
words,  the  initialization  process  will  again  follow  the  incrementing 
operation. 


2.  Operating  Modes 

The  program  AMTOHAP  features  six  distinct  operating  modes: 
normal,  printing,  recording,  dumping,  biasing,  and  Don  Site.  The  opera¬ 
tor  selects  these  modes  by  throwing  an  appropriate  breakpoint  switch  on 
the  computer  console  or  on  an  adjacent  electronic  panel.  By  throwing 
more  than  one  such  switch,  mixed  mode  operation  is  obtained. 

a.  Normal  Mode 

In  the  normal  operating  mode  the  program  AMTOHAP  receives 
data  from  AMRAD  and  hands  the  smoothed  data  to  HAPDAR.  No  tape  record¬ 
ings  are  made  in  this  mode  and  the  program  is  interrupt  driven. 
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b. 


Printing  Mode 


When  operating  in  this  mode  the  program  AMTOHAP  uses  the 
line  printer  to  output  data  as  it  is  received  and  calculated.  The  pro¬ 
gram  is  not  interrupt  driven  in  this  mode,  since  the  line  printer  limits 
the  speed  of  execution.  This  mode  is  used  primarily  for  debugging  and 
validity  checking. 

c.  Recording  Mode 

During  this  mode  of  operation,  the  computer  operates  in 
the  normal  mode,  except  that  the  collected  and  calculated  data  are  re¬ 
corded  on  magnetic  tape. 

d.  Dumping  Mode 

The  dumping  mode  is  used  to  transfer  the  data  recorded  on 
magnetic  tape  to  the  line  printer  for  direct  analysis  or  permanent  storage 
On  finishing  the  dump,  the  program  AMTOHAP  requests  a  teletype  input  to 
determine  whether  it  should  return  to  the  normal  mode  or  get  off  the 
computer. 


e.  Biasing  Mode 

When  operating  in  this  mode  a  30-dB  bias  is  added  to  the 
measured  signal  strength  to  account  for  attenuation  by  AMRAD's  clutter 
fence.  Otherwise  this  mode  is  identical  to  the  normal  one. 

f .  Don  Site  Mode 

The  Don  Site  mode  is  used  to  check  the  calibration  of 
AMRAD  and  HAPDAR.  When  the  breakpoint  switch  is  thrown,  incoming  AMRAD 
data  are  ignored  and  replaced  instead  with  the  known  Don  Site  coordinates 
Otherwise,  the  program  operates  in  the  normal  mode. 
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A  LISTING  OF  PROGRAM  AMTOHAP 


>END*CH. 

> assign  S=MT0W«Sl3Cfi»lOsLP»dO»PP,BI  =  PR*XI=MTllii*X2aMT2»t,)(3=MT3W. 

>ASSIGN  B0»MT2W. 

> ASSIGN  Hl*MT2W. 

>PE“!M)  MT2W. 

»F  ORTR  AN  SI*BQ*L0 

C  AMTOHAP  —  Vf«SION  II  —  SOS  920  AMRAD-TO-HAPDAR  HANDOVER  PROGRAM 

C  CONSOLE  BREAKPOINTS  —  2  «  PRINT  DATA,  3  a  RECORD  DATA,  A  a  DUMP  TAPE 

C  PANEL  BREAKPOINTS  —  9  »  SIGNAL  BIAS*  10  a  OON  SITE  COORDINATES 
C 

C  NOTATION  —  FIRST  CHARACTER  a  COORDINATE  MEASURED*  SECOND  CHARACTER  = 
C  MEASURING  RADAR*  THIRD  CHARACTER  a  TARGET  MEASURED,  ALSO*  Rx  RANGE, 

C  E  a  ELEVATION*  A  a  AZIMUTH  OR  SIN (ALPHA) ♦  B  ■  SlN(BETA).  ALSO* 

C  Ax  AMRAD  AND  H  a  hAPQAH,  ALSO*  SNR  >  S IGNAL-TO-NOISE  RATIO* 

C  T  x  TARGET*.  FOR  EXAMPLE*  EAT  ■  ELEVATION  UF  TARGET  AS  MEASUMbD  FROM 

C  AMRAD,  ALSO,  3  X  SINE*  C  a  COSINE. 

C  ALSO.  V  DENOTES  SECOND  TARGET  AND  I  AN  INTEGER  OUANTITY, 

C 

DIMENSION  IDATA(So«13) *UDATA(50*13) 

C 

C  DIMENSIONS  -  RANGE  a  METERS,  ANGLE  a  RADIANS.  TIME  a  SECONDS, 

C  SIGNAL  a  DBM  AT  AMRAD*  DBSNR  AT  HAPDAR 

C  INITIALIZE  FLAGS  AnO  SET  INTERRUPT  ADDRESSES 

16  REWINO  I 

IT  IFLGa-100 

JFLGa-100 
KFLGa-100 
LFLGa-100 
MFLGa-100 
IPARa-1 
CALL  SET 
C 

C  CYCLE  FILTER  ON  INCOMING  DATA 

IB  1  =  0 

JaO 
K»0 
C 

C  BASIC  FILTERING  loop  BEGINS  here 

20  1*1*1 

J*J*1 

c 

c  idle  program  here 

22  CALL  IDLE (IFLG.JFLG*KFLG»LFLG,MFLG) 

C 

C  ARM  AND  ENABLE  INTERRUPTS 

CALL  INT 
C 

C  CHECK  BREAKPOINT  SNITCHES 

CALL  CHKUPRTtIHCD.ISTP) 

C 

C  OUTPUT  SECOND-TARGET  COORDINATES  TO  HAPDAR  «HEN  JFLG  =  o  OR  KFLG=  i 

25  IF(JFLG)  26.2U25.26 

2 ('25  CALL  V0UT(IVRAT.IVAAT*IVEAT»IVSAT.1VTAT»ISIAT2*IPUMP) 

GO  TO  202? 

26  If'(KFLG)  2  t  *2026  *  2  7 

2( )2n  call  V OUT (IVHAT.IvAAT.lVEAT.lv SAT»IVTAT*1STaT2«I PUMP) 

C 

C  PRINT  COLLECTED  DATA 

2027  IFdPHD  27*127.27 

127  PRINT  15,IRAT.1AAT,IEA1.1SAT.ITAT,ISTAT1*IPUMP 

PRINT  IS.IVRaT.  lVAAT.IVt.AT,IVSAT.IV  TAT,  1ST  A  I  2.  IPlJMP 
PRINT  15* IFLG* JFLG.KFLG*LFLG»MFLG 
PRINT  15 
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•IVRAT 
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•IVAAT 
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3 

•01 

13 

•IVSAT 
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VOUT 

2 

2 

2 

2 
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SHALL  WE  SEND  DON  SITE  COORDINATES 


EXTRACT  RIGHT  17  BITS. 


EXTRACT  RIGHT  17  BITS. 


CLEAR  8 

PUT  LEAST  6  BITS  IN  LEFT  6  BITS  OF  A. 
MERGE  WITH  ELEVATION 
STORE  IN  ELEVATION 
COPY  B  REGISTER  TO  A  . 

CLEAR  8 

PUTS  MOST  6  BITS  IN  LEFT  6  BITS  OF  A. 

STORE  IN  AZIMUTH 

LOAD  A  REG  WITH  SIX-BIT  SIGNAL 
CLEAR  B  REG 

LEFT  CYCLE  AB  BY  2  BITS 
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CLEAR  B  REG 

LEFT  CYCLE  AB  BY  THREE  BITS 
ADD  ONE  TO  MERGED  SIGNAL 
CLEAR  B  REG 

LEFT  CYCLE  AB  REG  BY  13  BITS 
STORE  RESULT  IN  IVSAT 
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EXTRACT  RIGHT  17  BITS  OF  ELEVATION 

Jfc 

STA 

•IEAT 

w 

LOA 

•  ITAT 

LOAD  A  WITH  12-0IT  TIME 

clb 

CLEAR  B 

LCY 

18 

?UT  LEAST  6  BITS  IN  LEFT  6  BITS  OF 

MRG 

•IEAT 

MERGE  WITH  ELEVATION 

STA 

•IEAT 

STORE  IN  ELEVATION 

CHA 

COPY  B  REGISTER  TO  A  . 

CLB 

CLEAR  B 

LCY 

18 

PUTS  MOST  6  BITS  IN  LEFT  6  BITS  OF 

MRG 

•IAAT 

merge  with  azimuth 

41 

STA 

•  iaat 

STORE  IN  AZIMUTH 

LDA 

•ISAT 

LOAD  A  REG  WITH  SIX-BIT  SIGNAL 

clb 

CLEAR  B  REG 

LCY 

2 

LEFT  CYCLE  AB  BY  2  BITS 

MRG 

•ISTATl 

MERGE  STATUS  WITH  SIGNAL 

clb 

CLEAR  B  REG 

LCY 

3 

LEFT  CYCLE  AB  BY  THREE  BITS 

ADD 

=  01 

CLB 

CLEAR  B  REG 

LCY 

13 

LEFT  CYCLE  AB  REG  BY  13  BITS 

# 

STA 

•ISAT 

STORE  RESULT  IN  ISaT 

EOM 

030041 

POT 

•IRAT 

EOM 

"30220 

POT 

•IAAT 

EOM 

130201 

POT 

•IEAT 

EOM 

130021 

POT 

•ISAT 

BRR 

POUT 

DON 

DATA 

:)25713*  0340366*03640 16  *077 

PAGE 

SVOUT 

P  ZE 

OUTPUT  HaPDAH  VELOCIJY  OaTA 

Bhm 

20  ISYS 

XDS 

IVRaT 

XDS 

I  V  A  A  T 
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f-rar.~,ma irsrs*—** 


j 


RSH 

4 

DIVIDE  BY  TWO  TO  GET  ONE  DBM/BIT 

ETR 

■  077 

EXTRACT  RIGHT  SIX  BITS 

BPNT 

9 

CLUTTER  PENCE  CHECK 

BRU 

*♦5 

ADD 

=30 

ADD  30  DB  FOR  CLOTTEH  FENCE 

SKA 

*0100 

CHECK  FOR  OVERFLOW 

SRU 

i*2 

LDA 

*077 

place  ceiling  on  amrad  signal  strength 

STA 

•IVSAT 

STORE  SECOND  SIGNAL  IN  MEMORY 

LDA 

•ISAT 

LOAD  SIGNAL  INTO  A  REGISTER 

RSH 

12 

DIVIDE  BY  TWO  TO  GET  ONE  DBM/BIT 

ETR 

=  077 

EXTRACT  RIGHT  SIX  BITS 

BPNT 

9 

CLUTTER  FENCE  CHECK 

BRU 

*♦5 

ADO 

■30 

ADD  30  DB  FOR  CLLTTER  FENCE 

SKA 

*0100 

CHECK  FOR  OVERFLOW 

BRU 

5*2 

LDA 

*077 

PLACE  CEILING  ON  AMRAD  SIGNAL  STRENGTH 

STA 

•ISAT 

STORE  FIRST  SIGNAL  IN  MEMORY 

# 

LDA 

•ITAT 

PUT  TIME  IN  A 

clb 

RCY 

12 

MRG 

•ITIME 

STA 

•ITIME 

LDA 

•  ITAT 

RCY 

2 

ETR 

*01777 

EXTRACT  BITS  10-23 

STA 

SAVE 

SAVE  A  IN  SAVE 

LDA 

•ITAT 

PUT  TIME  IN  A 

RCY 

12 

RIGHT  CYCLE  AB  BY  12  BITS 

ETR 

*07777 

EXTRACT  LAST  12  BITS 

MUL 

*500 

MULTIPLY  A  BY  1000. 

CBA 

COPY  B  TO  A 

ADD 

SAVE 

ADO  SAVE  TO  A 

STA 

•ITAT 

PUT  A  IN  *ITAT 

# 

LDA 

•IVRAT 

LOAD  SECOND  RANGE  INTO  A  REGISTER 

ETR 

■  017 

EXTRACT  LAST  A  BITS 

STA 

SAVE 

PUT  LAST  4  BITS  IN  SAVE 

LDA 

•IVRAT 

LOAD  A  REGISTER  WITH  SECOND  RANGE 

RCY 

4 

RIGHT  CYCLE  A  REG  BY  4  BITS 

ETR 

•0777777 

EXTRACT  LAST  18  BITS 

MUL 

■5 

MULTIPLY  contents  OF  A  BY  10. 

CBA 

COPY  B  TO  A 

ADD 

SAVE 

ADD  SAVE  TO  A 

STA 

♦IVRAT 

PUT  A  IN  •IVRAT, 

BRR 

DIN 

IRAT 

RES 

2 

IEAT 

RES 

2 

IAAT 

RES 

2 

ITAT 

RES 

2 

ISAT 

RES 

2 

IVRAT 

RES 

2 

IVSAT 

RES 

2 

ISTAT1 

RES 

2 

I5TAT2 

RES 

2 

IPUMP 

RES 

2 

ITIME 

RES 

2 

SAVE 

RES 

1 

PAGE 

SPOUT 

PZE 

OUTPUT  HAPDAH  POSITION  DATA 

8RM 

201SYS 

xos 

IRAT 

XUS 

IAAT 

xns 

TEAT 
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BRING  AMRAO  data  In 


JD  IN 


* 


« 


RAGE 

pze 

BRM 

20  1  SYS 

XDS 

IRAT 

XDS 

I  A  AT 

XOS 

IEAT 

XDS 

1  SAT 

XOS 

I  TAT 

XUS 

ivhat 

XOS 

IVSAT 

XOS 

I  ST  AT l 

XOS 

ISTAT2 

XOS 

IPUMP 

XOS 

ITIME 

BRM 

2o2SYS 

EOM 

(34004 

PIN 

« I R  A  T 

EOM 

.30600 

PIN 

"IEAT 

tOM 

1 3  0  3  0  0 

PIN 

"IAAT 

EOM 

u34002 

PIN 

“ISA  T 

EOM 

30402 

PIN 

»itat 

EOM 

.'31010 

PIN 

"  I VRAT 

LOA 

"IRAT 

ETR 

=  017 

STA 

SAVE 

LOA 

"IRAT 

HCY 

4 

ETR 

=0777777 

MUL 

=5 

CB  A 

A  00 

GAVE 

STa 

"IRAT 

LOA 

"IEAT 

ETR 

=  037 

Cl.H 

LC  Y 

12 

ST* 

"ITIME 

LD« 

"IEAT 

HCY 

h 

ETR 

=  •.377  777 

STA 

"IEat 

LOA 

"I  AA  T 

HCY 

i 

ETR 

=  03 

STA 

"ISTrtTZ 

LOA 

"  i  a  a  r 

HCY 

! 

ETR 

=  .  1 

STA 

"IRlJMP 

LOR 

"  I A  A  T 

HCY 

4 

t  TH 

=  03 

STA 

"ISTAT1 

Ll'A 

"  I A  A  r 

hCY 

h 

t  TO 

=  1:  37  7  77  i 

STA 

i>  1  A  A  T 

Li)  A 

"ISAT 

LOAD  RANGE  INTO  A  REGISTER 
EXTRACT  LAST  4  BUS 
PUT  LAST  4  BITS  IN  S«VE 
LOAD  A  REGISTER  *1TH  RANGE 
HIGHT  CYCLE  A  REG  BY  4  BITS 
EXTRACT  LAST  16  BITS 
multiply  CONTENTS  OF  A  BT  lu. 
COPY  B  TO  A 
ADD  SAVE  TO  A 
PUT  A  IN  "IRAT • 

PUT  ELEVATION  IN  A 
EXTRACT  RIGHT  S  BITS 

LEFT  CYCLE  AB  BY  12  BITS 


RIGHT  CYCLE  AB  BY  SlxdiTS. 
EXTRACT  RIGHT  17  BITS. 

STORE  ELEVATION 

PUT  AZIMUTH  IN  A 

RIGHT  CYCLE  AB  BY  ONt  BIT. 

EXTRACT  STATUS  OF  SECOM)  TARGET 

STORE  STATUS  OF  SECOND  TARGET 

PUT  AZIMUTH  IN  A 

RIGHT  AB  BY  ThREc.  BITS 

EXTRACT  PUMP  SETTING 

STORE  PUMP  SETTING 

PUT  AZIMUTH  IN  A 

RIGHT  CYCLE  AB  BY  FOUR  BITS 

EXRTACT  STATUS  OF  FIRST  TARGET 

STORE  STATUS  OF  FIRST  IarGET 

PUT  AZIMUTH  IN  A 

RIGHT  CYCLE  AB  BY  SlxBifs 

EXTRACT  17  BITS  CF  AZIMUTH 

STORE  AZIMUTH 

LOAD  SIGNAL  INTO  a  RtGISIER 
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ERASE 

VFD 

Q  »rc 

500*0 

SINT 

PAGE 

PZE 

ARM  AND  ENABLE  INTERRUPTS 

AIR 

POT 

LOC 

EIR 

BRR 

INT 

LOC 

DATA 

000300000 

PAGE 

SIDLE 

PZE 

IDLE  LOOP 

BRM 

201SYS 

XDS 

IFLG 

INTERRUPT  RECEIVED  FLAG 

xos 

JFLG 

OUTPUT  FIRST  SCEOND-T ARGET  COORDINATES 

XDS 

KFLG 

OUTPUT  SECOND  SECOND-TARGET  COORDINATES 

XDS 

LFLG 

INPUT/OUTPUT  FIRST  DATA  SET  FROM  AMRAD 

XDS 

MFLG 

INPUT/OUTPUT  SECOND  DATA  SET  FROM  AMRAD 

BRM 

202SYS 

SKN 

•IFLG 

BRU 

S-l 

LDA 

»1 

STA 

•IFLG 

BRR 

IDLE 

IFLG 

RES 

2 

JFLG 

RES 

2 

KFLG 

RES 

2 

LFLG 

RES 

2 

MFLG 

RES 

2 

AREG 

RES 

2 

PAGE 

SSER30 

PZE 

SERVICE  AMRAD  MAINBANG  INTERRUPT 

STA 

MEG30 

LDA 

■-1 

STA 

•IFLG 

RESET  INTERRUPT  FLAG 

LDA 

REG30 

MIN 

•JFLG 

MIN 

•KFLG 

MIN 

•LFLG 

MIN 

•MFLG 

BRU 

•SER30 

REG30 

RES 

I 

SSER31 

PZE 

CLEAR  READ/WRITE  INTERRUPTS 

BRU 

•SER31 

SSET32 

PZE 

SERVICE  VELOCITY  SYNC  INTERRUPT 

STA 

REG32 

LDA 

*-l 

STA 

•IFLG 

RESET  INTERRUPT  FLAG 

LDA 

REG32 

BRU 

•SER32 

REG32 

RES 

1 

SSER33 

PZE 

CLEAR  READ/KRITE  INTERRUPTS 

BRU 

•SER33 

SSER200  PZE 

SERVICE  PREDICT  INTERRUPT 

STA 

HEG200 

LOA 

a-1 

STA 

•IFLG 

RESET  MAINBANG  INTERRUPT  FLAG 

LDA 

•-1 

STA 

•JFLG 

RESET  FIRST  SECOND-TARGET  OUTPUT  FLAG 

LDA 

a-b 

STA 

•KFLG 

RESET  SECOND  SECCND-T ARGET  OUTPUT  FLAG 

LDA 

aO 

STA 

•LFLG 

RESET  FIRST-DATA-SET  INPUT/OUTPUT  FLAG 

LDA 

a-5 

STA 

•  MFLG 

RESET  SECOND-DATA-SET  INPUT/OUTPUT  FLAG 

LOA 

HEG200 

BRU 

•SER200 

REG2O0 

1  NFS 

1 
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93  CALL  INT 

C 

c  RtCORD  COLLECTED  DATA  ON  TAPE  1  AFTER  FIFTY  CYCLES. 
90  IF(IRCD)  100*195,100 

195  IFII-50)  105,95.95 

95  IF  ( I  PAH  )  196,  196,197 

196  CALL  TAPEIIDATA) 

IPAR=*1 

GO  TO  *9 

197  CALL  TaPE(JUATA) 

IPAHs-1 

C 

99  K=K*I 

100  1=0 

105  IF(ISTP)  50,200,20 
C 

C  DUMP  COLLECTED  OATA  ON  PRINTER 

200  END  FILE  l 

PtWlND  1 
DO  250  1  =  1  , K 
CALL  CHK ( IPRT« IRCU, ISTP) 

IF(ISTP)  275*220,275 
220  CALL  GET(lDATA) 

PRINT  15 

250  PRINT  15,  ( ( IDATA ( 1 1 , JJ) * JJ=1 ,13) *  1 1  =  1 *50) 

275  REWIND  1 
C 

c  STAY  on  OR  get  off  machine 

ACCEPT  301, igo 
300  FORPAT(Il) 

IF  <lG0)lb.3U5,lb 
305  CONTINUE 
EM) 

>EOF 


>MET A92U  ST, 

LO.nO 

XOS 

OPD 

110000003 

VFD 

FORM 

l  0  *  1 A 

DEFINE  INTERRUPT  ADORESSES  AND  SPACE  TAPE 

SSET 

P2E 

TRT 

•  < ,  0 

bRU 

i>*2 

BRU 

5-2 

REW 

•  i,0 

TRT 

•ITAPE 

bRU 

b*2 

BRU 

5-2 

BTT 

!  , iTAPt 

bPU 

.'♦2 

bRU 

*>♦  1 

EFT 

»(• ,  IT  APE,4 

POT 

tMttSE 

LOA 

uEF  30 

STa 

30 

LOA 

uEF  3 1 

STA 

31 

LOA 

"EF  32 

STA 

32 

LDA 

)EF  33 

STA 

33 

LOA 

•JEF'200 

STA 

•  200 

rlWR 

SET 

DEF  3  i 

bhk 

SER31 

DEF  33 

l(DK 

SER1J 

DEF30 

bWr 

SER30 

DEFT2 

nPR 

sfc'«32 

DEF  20  0 

HR*' 

SFR200 
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15  FORMAT ( 1H  .13010) 

CALL  INT 
C 

C  RECORD  SECOND-TRACK  OATA 

IF(IPAR)  31.31.33 

31  IOATA  ( 1 .  9)»IVRAT 
IDATA(l.lo)»IVAAT 
10ATA(I,il)«IVEAT 
I0ATACI.12)«1VSAT 
IOATA ( 1. 13) *ITIME 

C  IOATA d» 13) ■64«64*KFLG-64*LFLG-MFLG 

GO  TO  27 

33  JDATAd,  9)>IVRAT 

JDATA ( I » 10 ) ■! VAAT 
JDATA(I. 11)«IVEAT 
JDATAd. 12)»IVSAT 
JDATAd. 13)>ITIME 

C  JOATA  ( 1 . 13)  ■6M64«KFLG-G4*LFLG-MFLG 

C 

C  READ  IN  AMRAO  DATA  IF  LFLG«0  OR  MFLG*0, 

27  IF (LFLG)  29.32.29 

29  IF(MFLG)  22.32.22 

C 

C  READ  IN  AMRAD  DATA.  SAVE  IN  DATA.  AND  CONVERT  TO  METERS. 

32  CALL  DIN(IRAT.IAAT.IEAT.ISAT.ITAT.IVRAT.1VSAT.ISTAT1.ISTAT2.IPUMPi 
1ITIME) 

IVAAT-IAAT 

IVEATMEAT 

IVTAT-ITAT 

C  USING  DOUBLE  BUFFERING  BECAUSE  OF  INTERLACED  TAPE  WHITE. 

IF(IPAR)  43. A3. 44 

43  IDATAII.DbIRAT 
IDAT  A ( 1 .2) >IAAT 
IDATAd.3)«lEAT 
IOATA (I .4) >ISA  T 
IOATA ( I ,4) bIvRAT 

C  IOATA (1,4) bISAT*64*IVSAT.4096*ISTAT1*B»409G*ISTAT2*64*4096*IPUMP 

GO  TO  45 

44  JDATAd, 1)bIRAT 
JDATAd, 2jbIAAT 
JDATAd, 3)bIEAT 
JDATAd, 4)bIVRAT 

C  J0ATA(I,41bIsAT*64*IVSAT*4096«ISTAT1*8«4096*ISTAT2*64»*096*IPUMP 

C 

C  SAVE  HAPDAR  PREDICTIONS 

C 

c  OUTPUT  FIRST-TARGET  COORDINATES  TO  HAPDAR. 

118  CALL  POUTdRAT,IAAT«ItAi,ISAT,ITAT»ISTATl,IPUMP> 

C 

IF ( IPAR)  121,121*122 

121  IOATA  < l ,5) bIRAT 
IDATA  d  ,6)  dAAT 
I0ATA(I,7)bIEAT 
I0ATA(I,B)bISAT 
GO  TO  123 

122  JOATA( I,5)»IRAT 
JDATAd.  6)bIAAT 
jDATAd»7)Bl£AT 
JDATAd, 8)bISAT 

C 

C  PRINT  COLLECTED  DATA 

123  IF(IPRT)  90,97,90 

97  IF  ( IPAR)  91.91,92 

91  PRINT  15,  dUATA(I,KK)»KKBl,l3) 

GO  TO  93 

92  PRINT  15.  (JOATA(I.KK) ,KKb1.i3) 
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FITTING  PROGRAM  TRANFT 

This  section  of  the  report  describes  the  IBM  360/65  fitting  program 
TRANFT  as  well  as  the  various  methods  used  to  validate  its  operation. 

A.  Objective  of  Fitting  Program 

The  purpose  of  the  program  TRANFT  is  to  take  data  received  from 
AMR AD,  convert  them  to  IIAPDAR  coordinates,  smooth  them  with  a  tracking 
filter,  and  then  give  the  fitted  data  to  the  HAPDAR  operating  system. 

The  RCA  routine  VPAS  calls  TRANFT  into  operation  on  receipt  of  new  data 
from  AMRAD.  TRANFT  in  turn  calls  the  SRI  routine  QUECOR,  after  fitting 
the  new  data.  The  AMRAD-to-HAPDAR  coordinate  conversion  and  trajectory 
smoothing  are  performed  within  TRANFT  by  algorithms  developed  at  SRI. 

B.  Description  by  the  Program  TRANFT 

The  program  TRANFT  is  an  interrupt-driven  algorithm  that  provides 
track  initialization  information  to  HAPDAR  from  AMRAD.  Its  historical 
development,  mathematical  structure,  and  logical  structure  are  outlined 
in  turn  below. 

1 .  Historical  Development 

The  program  TRANFT  evolved  from  software  developed  in  earlier 
contract  work.  Several  tracking  filters  were  designed  and  tested  against 
AMRAD  Athena  data  to  determine  CPU  demands,  memory  requirements,  and 
tracking  ability.  These  included  a  Kalman  filter,  a  least-square 
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processor,  and  a  Type- II  filter.  The  Kalman  filter  algorithm  was  found 
to  consume  both  excessive  CPU  time  and  excessive  main  storage,  as  well 
as  suffering  instability  when  processing  real  radar  data.  The  least- 
squares  algorithm  on  the  other  hand,  although  requiring  considerably  less 
CPU  and  storage,  still  required  too  much  fast  memory.  Experimentation 
with  the  Type- II  filter  indicated  that  its  CPU  and  memory  requirements 
were  tolerable,  and  that  it  remained  stable  under  all  tracking  conditions. 
Accordingly,  this  filtering  algorithm  was  selected  for  use  in  the  field 
demonstrations  at  WSMR. 

During  an  early  phase  of  the  contract  work,  an  adaptive  Type- I I 
filter  was  designed  and  fitted.  The  purpose  of  this  algorithm  was  to 
vary  the  filtering  constants  according  to  the  amount  of  vehicle  accelera¬ 
tion  detected.  That  is,  large  constants  are  derived  when  the  vehicle  is 
accelerating  to  suppress  acceleration  lag;  similarly,  small  constants  are 
derived  when  the  vehicle  is  coasting  to  obtain  well-smoothed  coordinate 
estimates.  The  algorithm  proved  very  effective  in  tests  at  SRI  on  Athena 
data,  but  tended  to  use  excessive  computer  time.  Accordingly,  the  con¬ 
cept  of  variable  filter  constants  was  dropped  in  the  work  that  followed. 

In  addition  to  the  coordinate  estimating  code  obtained  from  the 
original  version  of  AMTOHAT,  algorithms  were  needed  to  assess  the  errors 
associated  with  the  position,  velocity,  acceleration,  and  SNR  estimates. 
These  algorithms  were  obtained  by  extending  the  Type-II  filter  theory. 

That  is,  the  predicted  coordinates  were  compared  with  the  measured  ones 
and  the  differences  used  to  estimate  the  errors  in  the  filtered  values. 

(The  details  of  the  technique  are  described  in  more  detail  below.) 

2.  Mathematical  Structure 

,  The  tracking  filter  built  into  TRANFT  was  designed  especially 
for  WSMR  field  demonstrations.  The  tracking  algorithm  uses  an  optionally 
adaptive  Type  II  filter  to  obtain  its  position  and  velocity  estimates,  and 


an  optionally  adaptive  Type  I  filter  for  its  acceleration  and  SNR  estimates. 
This  filter  is  considered  superior  to  both  the  Type-11  and  Kalman  algorithms 
for  the  stated  field  applications. 

I 

a.  Filter  Design  Requirements 

In  designing  the  TRANFT  filter  the  following  requirements 

were  imposed: 

•  The  filter  should  process  the  incoming  data  re¬ 
cursively  to  conserve  fast  memory  and  central 
processor  time. 

•  The  filter  should  generate  a  vehicle  state 
vector  and  its  associated  error  covariance 
matrix. 

•  The  filter  should  adapt  dynamically  to  tracking 
errors,  mathematical  nonl inear i t  ies,  plant  noise, 
and  target  fading. 

To  conserve  computer  resources  and  make  optimum  use  of  the 
radar  measurements,  the  trajectory  filter  should  operate  recursively  on 
the  input  data.  That  is,  the  new  trajectory  estimate  should  be  obtained 
by  modifying  the  old  estimate  using  the  latest  radar  measurement .  This 
technique  contrasts  with  the  nonrecursive  procedure  wherein  the  oldest 
measurement  is  dropped  in  favor  of  the  new  one  and  trajectory  reestimated 
with  the  fitting  algorithm.  Unlike  the  recursive  technique,  the  latter 
procedure  fails  to  take  advantage  of  previous  mathematical  work,  and  thus 
unnecessarily  burdens  the  digital  computer  facilities. 

To  accomplish  handover  and  correlation,  the  trajectory 
filter  should  provide  estimates  of  both  the  vehicle's  state  vector  and 
its  error-covariance  matrix.  For  the  purposes  of  reentry  vehicle  tracking 
a  six-component  position/velocity  state  vector  has  proven  adequate.  To 
perform  the  required  target  correlation  one  also  needs  the  associated 
6X6  error-covariance  matrix.  When  predicting  ahead  for  handover  or 
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adapting  the  filter  to  high  acceleration  vehicles,  a  nine-component 
position/velocity/acceleration  state  vector  is  preferred. 

Experience  indicates  that  field  demonstrations  encounter 
such  problems  as  target  jumping  by  the  AMRAD  tracker,  nonlinearities  in 
the  handover  coordinate  transformation,  plant  noise  in  the  vehicle's 
equations  of  motion,  and  signal  fading  due  to  target  motion.  Accordingly, 
it  is  desirable  to  have  the  trajectory  filter  adapt  and  recover  from 
such  errors  as  they  occur.  Toward  this  end  the  filter  should  have  the 
capability  to: 

(1)  Weight  the  incoming  data  more  heavily 

than  the  old  data  to  suppress  cumulative 
type  mathematical  errors;  cumulative  type 
fitting  errors;  target  jumping  errors;  and 
errors  due  to  irregularities  in  the  vehicle's 
equations  of  motion,  inaccuracies  in  the 
atmospheric  densities,  and  nonlinearities 
in  the  handover  coordinate  transformation. 

(2)  Adjust  the  magnitude  of  the  filtering  constants 
according  to  the  recorded  signal-to-noise 
ratio  in  order  (a)  to  optimize  the  use  of  the 
incoming  data  and  (b)  to  coast  the  vehicle  s  state 
vector  through  periods  of  target  fading. 

(3)  Adjust  the  magnitudes  of  the  filtering  constants 
according  to  the  vehicle  acceleration  in  order 
to  reduce  tracking  lag  during  periods  of  high 
vehicle  acceleration. 

(4)  Derive  the  error-covariance  matrix  from  the 
measured  errors — rather  than  the  measured  SNR — 
so  that  the  error  assignments  remain  tied  to 
radar  measurements. 


b.  Definition  of  Symbols 


For  convenience  the  various  mathematical  symbols  used 
herein  are  defined  below: 
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Z  =  predicted  AMRAD  state  vector 
P 

Z  =  estimated  AMRAD  state  vector 
e 

Z  =  measured  AMRAD  state  vector 
m 

E  =  error-covariance  matrix 

F  =  transition  matrix 

C  =  error-correction  matrix 

H  =  coordinate-conversion  matrix 

t  =  time  at  which  measurement,  prediction,  or 
estimate  is  valid. 

The  state  vector,  Z,  is  columnar  and  has  the  following 
ten- component  form: 

Z  =  (PR,  PE,  PA,  VR,  VE,  VA,  LR,  LE,  LA,  SNR) 

where  P  =  position  coordinate,  V  =  velocity  coordinate,  and  L  -  lag 
coordinate.  Also,  R  =  range,  E  =  elevation,  A  =  azimuth,  and  SNR  - 
signal-to-noise  ratio.  (In  practice,  an  eleventh  component,  the  time  t 
might  be  added  to  complete  the  state  vector  Z.) 

c.  Predicting  Ahead 

Given  the  estimated  state  vector,  Z^,  and  the  estimated 
error  matrix,  E  ,  the  trajectory  filter  predicts  ahead  one  sampling 
interval  At  using  the  transition  matrix  F: 

Z  (t  +  At)  =  FZ  (t) 

P  e 

T 

E  (t  +  At)  =  FE  (t  +  At)F 
P  e 
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Basically,  the  transition  matrix  predicts  the  new  vehicle  position  by 
adding  a  velocity  increment  to  the  old  position  estimate.  (For  handover 
an  acceleration  increment  is  also  added.)  To  keep  the  filtering  stable, 
the  velocity  and  acceleration  are  not  modified  by  the  transition  matrix 
F.  That  is,  the  velocity  and  acceleration  predicted  for  the  time  t  +  At 
equal  the  velocity  and  acceleration  estimated  at  the  time  t. 


d.  Making  Corrections 

The  tracking  filter  next  corrects  the  predicted  state 
vector,  using  the  new  AMRAD  measurements: 

Z  =  Z  +  C(Z  -  HZ  ) 
e  p  m  p 


The  velocity  coordinates  are,  of  course,  not  measured  by  AMRAD.  Accord¬ 
ingly,  the  corresponding  elements  of  Z^ — but  not  Z^  are  set  equal  to 
zero.  (The  error-correction  matrix  C  is  described  in  detail  in  Section 
e  below. ) 


The  coordinate-conversion  matrix  H  serves  to  zero  the 


unmeasured  components  of  the  state  vector  Z  .  Accordingly,  it  has  the 

r 

following  form: 


1 
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This  matrix  assumes  a  more  interesting  form  when  the  measurements  are 
made  in  one  coordinate  system  and  predictions  in  another.  (As  noted 
below,  the  vehicle  lag  coordinates  are  considered  measured.) 

The  estimated  error-covariance  matrix  Eg  is  interpreted 
as  a  weighted  average  of  the  prediction  and  measurement  errors: 

T  T 

E  =  (1  -  CH)E  (1  -  CH)  +  CE  C 
e  P  m 

(This  formula  can  be  derived  by  looking  at  the  variance  of  Zg.)  It  is 
highly  desirable  to  keep  the  estimated  error-covariance  matrix  tied  to 
the  errors  actually  measured  by  the  AMRAD  radar.  Accordingly,  the  measure¬ 
ment  errors  are  approximated  with 


m 


(Z  -  HZ  )  (Z  -  HZ  )' 
m  p  m  P 


That  is,  the  variance  in  the  coordinate  measurements  is  set  equal  to  the 
difference  between  the  measured  and  predicted  coordinates. 

e.  Nature  of  the  C  Matrix 

The  error-correction  matrix  C  performs  the  following  four 
basic  operations  on  the  vehicle  state  vector. 


Correct  Predicted  Position— The  estimated  vehicle  posi¬ 
tion  is  equal  to  the  predicted  position  plus  a  small  correction.  The 
correction,  in  turn,  is  proportional  to  the  difference  between  the  mea¬ 
sured  and  predicted  positions.  That  is,  the  estimated  position  takes 

the  basic  form: 

P  =  P  +  C  (P  -  P  ) 
e  p  P  m  p 
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where  0  <  C  <  1.  The  magnitude  of  Cp  is  largely  determined  by  the 
desired  time  constant  for  the  tracking  filter. 


Correct  Predicted  Velocity — Upon  reception  of  new  AMRAD 
data,  the  C  matrix  calculates  a  new  velocity  estimate  by  adding  a  small 
correction  to  the  predicted  velocity.  (As  noted  above,  the  predicted 
velocity  equals  the  previously  estimated  velocity.)  The  correction,  in 
turn,  is  proportional  to  the  difference  between  the  measured  and  pre¬ 
dicted  velocities: 


V  =  V  +  C  (V  -  V  ) 
e  p  V  m  p 

=  V  +  C(P  -  (P  -  V  )  -  V  ) 
p  V  m  P  P  P 

=  V  +  c  (P  -  P  ) 
p  V  m  p 

Note  that  V  is  the  distance  the  vehicle  travels  in  the  time  interval 
P 

At.  The  constant  is  chosen  so  that  the  filter  remains  stable.  That 
is,  Cy  is  chosen  small  enough — relative  to  Cp — to  make  the  filter 
slightly  less  than  critically  damped. 

Average  Acceleration  Lags — A  Type- II  filter  makes  no 
provision  for  vehicle  acceleration.  The  predicted  position  may  be  ex¬ 
pected  to  lag  an  accelerating  vehicle  and  lead  a  decelerating  one.  The 
measure  lag  (or  lead)  is  defined  by 

L  =  P  -  P 
m  m  p 

The  error-correction  matrix  thus  performs  a  weighted  average  of  the  pre¬ 
dicted  and  measured  acceleration  lags: 
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L 

e 


L 

P 


(1  -  C  >  +  C 


L 

L  m 


=  L  +  C  (L 
p  L  m 


L  ) 
P 


The  constant  C  must  be  chosen  large 
L 

celeration  estimate  and  small  enough 
measurement  error . 


enough  to  obtain  an  up-to-date  ac- 
to  suppress  fluctuations  due  to 


Average  Measured  SNRs— Like  the  acceleration  lag  coordi¬ 
nate,  it  is  desirable  to  average  the  measured  SNR  over  several  radar 
returns  to  eliminate  pulse-to-pulse  fluctuations: 

™  =  simp  +  Vs". '  SWV  ■ 

The  constant  C  must  be  small  enough  to  smooth  the  measured  data,  but 
SNR 

large  enough  to  detect  target  fading  when  it  occurs. 


f .  Form  of  the  C  Matrix 

According  to  the  above  discussion,  the  C  matrix  takes  the 
following  sparse-matrix  form: 


C  0 
PR 


0  C 
0 


PE 

0  C 


0 

0 


PA 

0 


c  o 

VR 


0  C  0 
VE 


0 

0 

0 

0 

0 


VA 

0 


0  c 

0 

0  0 
0  0 
0  0 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


0 

0 

0 

0 

0 

0 

c 


0 

0 

0 

0 

0 

0 

0 


LR 

0  c. 
0 
0 


0 

0 

0 

0 

0 

0 

0 

0 


LE 

0  c. 

0 


0 

0 

0 

0 

0 

0 

0 

0 

0 


LA 

0  c 


SNR 
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g ,  Variations  of  the  C  Matrix 

The  elements  of  the  C  matrix  are  varied  according  to  (1) 
the  amount  of  acceleration  detected  by  the  tracking  filter  and  (2)  the 
target's  measured  signal-to-noise  ratio,  as  described  below. 

Acceleration  Variations— During  reentry  the  vehicle  de¬ 
celeration  can  become  quite  large.  To  follow  such  vehicles  it  is  desirable 
to  enlarge  the  elements  of  the  C  matrix  when  high  decelerations  are  de¬ 
tected  by  the  tracking  filter: 


A  +  A 
o  P 

This  formula  provides  a  continuous  transition  from  the  low-acceleration 

constants  (C  >  to  the  high-acceleration  constants  (C^),  with  the  cross- 
LO 

over  point  determined  by  the  constant  Aq. 

SNR  Variations— Poor  signal-to-noise  ratios  increase  the 
error  in  the  measured  coordinates  according  to  the  usual  radar-error 
formula: 

measurement  error  =  antenna  ambiguities 

+  noise  fluctuations 

The  antenna  ambiguities  depend  on  the  diameter  of  the  radar  aperture  and 
the  accuracy  of  its  calibration.  Noise  fluctuations  vary  inversely  as 
the  square  root  of  the  SNR.  To  optimize  the  use  of  the  radar  measurements 
the  coordinate  estimates  should  be  made  by  forming  a  weighted  average  of 
the  predicted  and  measured  coordinates.  The  weighting,  in  turn,  should 
depend  on  the  relative  errors  in  the  predicted  and  measured  coordinates. 
That  is,  the  magnitude  of  the  C  matrix  elements  should  vary  directly  with 

the  ratio: 
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pred iction  error _ 

prediction  error  +  measurement  error 


Because  the  SNR  can  vary  through  several  orders  of  magm 
tude  as  the  target  signal  strengthens  and  fades,  the  above  ratio  looks 
like  a  step  function  when  plotted  against  the  possible  values  of  the  SNR. 
The  step  occurs  when  the  noise  fluctuations  begin  to  dominate  the  antenna 
ambiguities  in  the  radar-error  formula  quoted  above.  Accordingly,  it  is 
recommended  that  the  elements  of  the  C  matrix  depend  on  the  SNR  accord¬ 
ing  to  the  following  formula: 

C  =  C  step  (SNR  -  SNR  )  • 

o  ° 

Here  step  (x)  equals  1  if  x  >  0,  and  equals  0  of  x  <  0. 


C.  TRANFT  Flow  Chart 

To  ease  the  programming  effort  and  allow  fast  debugging,  the  program 
TRANFT  was  designed  using  modular,  rather  than  in-line,  code.  A  flow 
chart  of  TRANFT  is  shown  in  Figure  B-l.  A  listing  of  TRANFT  will  be 
found  at  the  end  of  this  Appendix. 

1.  Initialize  Filter  (Begin,  Start) 

The  tracking  filter,  vehicle  state  vector,  and  error- 
covariance  matrices  are  initialized  when  TRANFT  is  first  called.  In 
particular,  the  subroutine  BEGIN  sets  up  the  filter-constant  matrix  C, 
its  identity-matrix  complement  CC,  its  transpose  CT,  and  the  identity- 
matrix  complement  of  the  transpose  CCT.  In  addition,  the  rotation  and 
translation  constants  needed  to  convert  AMRAD  measurements  to  HAPDAR 
coordinates  are  defined. 

The  tracking  filter  uses  the  first  four  sets  of  AMRAD  data  to 
initialize  the  vehicle  state  vectors  and  the  covariance  matrices.  (The 
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SA-1853 


figure  b-1  block  diagram  of  tranft 
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first  and  third  sets  of  data  initialize  the  first  vector  and  matrix,  and 
the  second  and  fourth  sets  initialize  the  second  vector  and  matrix.) 
Two-pulse  initialization  is  used  to  set  up  the  position  and  velocity 
coordinates.  The  acceleration  lag  is  set  equal  to  10  percent  o+  the 
respective  vehicle  position  coordinates,  and  the  SNR  is  set  equal  to  the 
last  AMRAD  reading. 

The  error  covariance  matrices  are  established  by  assuming  an 
initial  range  error  of  30  meters,  an  initial  angle  error  of  4  milliradians, 
an  initial  velocity  error  of  20  times  the  respective  position  error,  an 
initial  lag  error  equal  to  the  initial  position  error,  and  an  initial  SNR 
error  equal  to  10.  Although  somewhat  arbitrary  and  artificial,  these 
numbers  worked  out  very  satisfactorily  in  actual  field  tests. 

2.  Update  Clock,  Identify  Data 

Following  filter,  vector,  and  matrix  initialization,  the  program 
TRANFT  goes  into  a  normal  processing  mode.  As  new  data  is  received  it 
is  just  used  to  update  the  program  clock,  as  held  in  the  word  VTIME. 

Next,  TRANFT  determines  whether  the  transmitted  data  applies  to  the  first 
or  second  vehicle  being  tracked  by  AMRAD.  Following  the  identification, 
the  handover  counters,  I  HAND  or  J  HAND,  are  incremented  and  the  identi¬ 
fication  and  status  bits  stored. 

3,  Data  Retrieval  (GETBK) 

The  program  TRANFT  uses  the  identification  word  IDENT  to  re¬ 
trieve  the  vehicle  state  vector  and  error-covariance  matrix  from  common 
memory.  Because  vehicle  velocities  are  stored  in  units  of  meters/second 
and  filtering  carried  out  in  meters/pulse,  time  scaling  is  required  for 
both  the  state  vector  and  error  matrices. 
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4. 


Predict  Ahead  (UPDATE) 


Using  the  retrieved  estimates,  the  program  TRAN FT  next  predicts 
ahead  (actually  updates)  to  the  time  of  the  newly  received  AMRAD  data. 

The  state  vector  prediction  is  accomplished  by  multiplying  the  estimated 
state  vector  times  one  F  matrix.  The  error-covariance  prediction  is  ob¬ 
tained  by  premultiplying  by  F  and  post-multiplying  by  the  transpose  of  F. 

5.  Data  Setup  (SETUP) 

The  program  TRANFT  next  calls  SETUP  to  perform  the  required 
coordinate  transformation  between  AMRAD  and  HAPDAR.  (The  coordinate 
transformation,  which  is  performed  in  the  subroutine  COOR,  is  described 
in  Ref.  2.)  Following  coordinate  conversion,  the  measured  data  is  set 
into  the  array  DATA.  During  this  operation  the  program  compensates  for 
any  bias  as  scaling  errors  between  the  two  radars.  (These  arise  because 
of  inaccurate  surveys,  misaligned  clocks,  and  software  bugs  at  HAPDAR.) 

6 .  Vector  Convection  (CORVEC) 

The  program  TRANFT  next  uses  the  measured  data  to  correct  the 
state-vector  prediction  made  by  UPDATE.  The  correction  is  made  by  adding 
part  of  the  difference  between  the  measured  and  predicted  values  to  the 
predicted  state  vector.  The  filter  constant  matrix  C  determines  the 
magnitude  of  the  addition. 

7 .  Matrix  Correction  (CORMAT) 

The  program  TRANFT  next  uses  the  measured  data  to  form  a  matrix 
of  the  measured  errors.  This  matrix  is  formed  by  considering  the  dif¬ 
ferences  between  the  measured  and  predicted  vehicle  coordinates.  The 
subi ou tine  CORMAT  then  corrects  the  predicted  error— covariance  matrix  by 
adding  a  part  of  the  difference  between  the  predicted  and  measured  errors 
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The  magnitude  of  the  addition  is  de- 


to  the  predicted  error  matrix, 
termined  by  the  filter-constant  matrix  C. 

8 .  Data  Storage  (PUTBK) 

Following  correction  of  the  predicted  state  vector  and  erioi 
covariance  matrix,  the  program  TRANFT  calls  PUTBK  to  put  the  new  esti¬ 
mates  back  in  common  memory.  During  this  operation  the  data  is  scaled 
back  from  meters/pulse  to  meters/second,  consistent  with  the  BMDOS  measure¬ 
ment  units. 


9.  QUECOR,  SRIBLD 

Having  completed  its  tasks,  TRANFT  next  calls  QUECOR  and  SRIBLD 
to  carry  out  the  vehicle  correlation  and  track  initialization,  respec¬ 
tively.  Following  execution  of  these  routines,  TRANFT  exits  from  the 
system. 


onononoonooo 


A  LISTING  OF  SUBROUTINE  TRANFT 


PH0GRAM  MaIN(INPUT, OUTPUT) 

C  THIS  ROUTINE  JUST  CALLS  ThE  SUBROUTINE  TRANFT. 

data  IPHT/9/ 

CALL  SECO  jD(TI) 

NN=54 

DO  10  I » l »  NN 
call  GETAM(IPRT) 
call  tranpt 

10  CONTINUE 

CALL  SECOND (T2) 

TE=T2-T1 
RExTE/ (NN-4) 

PRINT  7‘i  *  T1  *  T2  * TE » HE 
75  FORMAT ( 1H  .4E15.7) 

END 

SUBROUTINE  GETAM ( IPRT) 

C  THIS  ROUTINE  (NOT  USED  AT  IBM  360/b5)  FILLS  RSDS  FOR  CHECK-OUT 

DIMENSION  IUATA(lO) 

COMMON  Rll .R12.R 13 ,R21 .N22.R23.H31 .H32,KJ3. ASCL.ANG.XAH.YAH.ZAH 
C0MMON/RSi>S/DUMMY1,VRa!«G£,VaZIMH,vELEV.VSNR*DUMMY2,VTIME. 

1  IS  1  * IS2 »  ID  1 . IU2 

DOUBLE  PRECISION  T IMEt VT IME • VEC1 » T IME1 • ECM1 . VEC2. T IME2.ECM2 
DATA  TwOPI/6. 283 1853070/ 

DEFINITION  OF  ELEMENTS  OK  VECTOR  IDATA  — 

1  a  AMRADRANGE  (LEAST  COUNT  a  1 .B737055/1 .25  METERS) 

2  a  AMRAD  ELEVATION  (LEAST  COUNT  «  1/16777216  OF  A  CIRCLE) 

3  a  AMRAD  AZIMUTH  (LEAST  COUNT  x  1/16777216  OF  A  CIRCLE) 

4  a  HAPOAW  SIGNAL  LEVEL  ( AGC  SETTING  IN  UBSNR) 

5  x  RANGE  TIME  (LEAST  CUUNT  a  ONE  MILLISECOND) 

6  x  DATA  SOURCE  (1  »  AMHaO.  0  *  RAS) 

7  a  TAHGET  (n=  PRIMARY  1 ARGET i  l  x  SECONDARY  TARGET) 

B  a  TRACKING  MODE  (00  »  MANUAU01  ■  ACQUISITION*  11  a  AUTOTRACK) 

9  a  UNUSED 

10  a  UNUSED 

READ  1. (IJATA(I) *I=l*a> 

1  FORMAT (lOOB) 

IDATA (9)  =  t 
C 

ASCL«1. 8737055/1. 25 
VRANGEaASCL*IDATA() ) 

VAZIMHxTWOPIMOATA  (3  )  /16777216  » 

VELEVaT<*OPI*IDAT  A  (2) /167  7721b. 

VSnRbIDAT  A (4) 

VTIME»1I)ATA(5)/2000. 

IOl-IDATA (6) 

I02aIDAT  A ( 7) 

IS1»IDATA (8) 

IS2»IDATA (9) 

C  DON  SITE  CHECK  CUT 

IF  (  0 )  111.111.112 

111  VHANC,E»I68.i9.JB28 
VAZIMH=2.  i5B9Hb-TW0RI/2. 

VELEVab, 279734 

(;*•*••••«•«*•»» 

112  IF  C IPRT)  2u.20.lJ 

10  PRINT  45 1 «VRANGE.VaZIMH*VELEV . VSNR .VTIME.ISI.IS2.ID1.1D2 

45]  FORMAT  (  IH  .4E12. 5. 012,5. 6I(i) 

20  RETURN 

END 

SUBROUTINE  SRIHLU 
C  DUMMY  SUOHUUTTUE 
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c 


c 

c 

c 

c 

c 


c 


c 

c 

c 

c 

1 

2 

c 

c 


3 

c 

c 

c 

c 

13 


c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

5 

c 

c 

6 


RETURN 

END 

SUBROUTINE  UUECOR 
DUMMY  SUBKOUT I  it 
RETURN 
END 

SUBROUTINE  TRANK T 


THIS 

FITS 

WITH 


ROUT 1NE 
pus i r  on 
A  TYPE- 


THm NF'jRMS  MEASUREMENTS  FROM  aural)  TO  HAUAR,  AND  THEN 
AND  VEUClTt  WITH  A  TYPE"2  FlLltR,  ACCELERATION  LAO 
1  FILTER*  RNU  SNR  WITm  A  TYPt-l  FILTER* 


DIMENSION  STaTEI 10) ,EHRUR(10,IU) *C(10*10> * 

1  OATA(lO)  *VEC1  tin)  »ECMl(ld,iO>  * 

2VEC2110) *  ECM2 (  in  *  in) »CT  (10*10) *CC!10*10) *CCI  (10*10) 

COMMON  Hli,Rl2.Rt3,R21.H22,R23.H31,R32,P33,ASCL.ANG,JAH,YAH,ZAH 

COMMON/RSJS/DUMM  Y 1  *  V  RANGE  ,  VAZIMHtVELEV  *  V  SNR  *  DUMMY  2  *  V  T  I  ME  * 

^COMMON/ AMT  RK/V  EC  l  *  T  I'^Ll  *  I  SI  l  *  IS12*  101 1 «  1012»ECMl  . 

1VEC2* TIMES* 1S21 *  IS22* IU21 * ID2? »ECM2 * IDUM 1  * 1UUM2 

SET  IPRT  =  l  FUR  PRINT  OUT.  SET  IPRT  *  0  FOR  NO  HWInT  OUT. 

DATA  ICYCLE, IPHT/-4.1/ 

DOUBLE  PRECISION  TlME*VflME,V£Cl*TIMEl,ECMl*VEC2,TiME2,ECM2 


FORMAT ( 1H  ,6110) 

FORMAT ( 1H  ,adI2.S.4E12.U) 

ICYCLE  =  NUMBER  OF  TIMES  HSDS  HAS  BEEN  RtAO 

ICYCLE=ICYCLEMl 

IF ( ICYCLE )  3,3,5 

IF ( ICYCLE*?)  13 , 1a , 1 A 


INITIALIZE  PROGRAM 
INITIALIZE  FILTERING  MATRICES. 

TRANP  aTiD  H  NO  LONGER  USED  BY  THIS  PRUGRAM( 
CALL  HEGI  1(C,CT,CC,CCT,IPRT) 
call  PUT Ah ( IDENT ,STATE»U* IPRT) 

CALL  PUT A  1  ( IDENT ,5  TATE *gT, IPRT) 

CALL  PUT AH ( 10ENT.S  TATE *CC, IPRT) 

CALL  PUTA  ill  DENT, STATE* CCT, IPRT) 


IH AND  *  COUNTER  FCR  FIRST  VEHICLE 

IHAND=-10  .  ,  _ 

JHAND  =  COUNTER  FCR  SECONO  VEHICLE 
Jh ANOa-2  0 

INITIALIZE  STATE  VECTORS  a NO  ERROR  COVARIANCE  MATRICES. 
CALL  START ( ICYCLE, I PUT) 

TIME  =  PROGRAM  TIME*  VTlMl*  s  HSDS  TIME, 

TIMEaVTIMt. 

RETURN 

FILTER  INCOMING  DATA. 

IUENT  =  1  FOR  VEHICLE  ONE,  IOENf  *  2  FOR  VEHICLE  Two. 

IUENT=ID2*l 

IF  (  IDEnT-1 )  6,6,10 

FIRST  target  UATT. 

DELTA«vTI'1E-TIMEI 

TIME=VTIMi. 

TImFIbTIMI 


I 


lHAND=  IHANU* ) 

IS11=I51 
IS12«IS2 
1011*101 
ID12=ID2 
GO  TO  19 

c 

C  SECOND  TARGET  UATA, 

10  DELT  A=VT IME-TIME2 
TIME=VTIMt 
TIME2=TIME 
JHAND*JHA  1U*1 
IS21*IOl 
IS22«ID2 
1021=101 
ID22«I02 
C 

C  GET  OLD  ESTIMATES  FROM  AMTRK  FILE. 

19  CALL  GETBK  ( IllENTf  STATEftHHOR) 

CALL  POT  AH  (  IdEnT,  STATE*  ERROR  •  IPRT) 

C  UPDATE  OLi)  ESTIMATES  HY  ONE  PULSE  TIME. 

23  CALL  UPDATE  (STATE .ERROR  *  DEL T  A ) 

CALL  PUT AM ( IOENT .STATE* ERROR* IPRT) 

C 

C  SET  UP  THE  MESUREPENT  VECTOR  FOR  FILTERING. 

CALL  SETUP(STATE.OaTA.IPRT) 
call  PUTAM(IDEnT.DATA  »£RROR»IPRT) 

C  CORRECT  TnE  UPDATED  STATE  ESTIMATES  USING  TmE  NEW  MEASUREMENTS. 
25  CALL  CORVEC (STATE, C.DaTA) 

CALL  PUT AM ( IDENT, ST ATE* ERROR, IPRT) 

C  CORRECT  THE  UPDATED  ERROR  ESTIMATES  USING  THE  NEW  MEASUREMENTS. 
CALL  CORMaT (STATE, DATA. ERROR, C.CC.CT • CC T ) 

CALL  PUT Am ( 1 DENT, ST ATE* ERROR, IPRT) 

C 

c  PRINT  OUT  KEY  NUMBERS 

IF  ( IPRT )  72,72,71 

71  PRINT  I,  1CYCLE,IHANU,JNAND,I0EnT 
PRINT  1,IS1»IS2,I01»IU* 

PRINT  1,IS11,IS12,IU11,IU12 
PRINT  1,IS21,IS22, 1021*1022 

PRINT  2,VTIME*TIME.TIMtl,TIME2,VRANGE,VA2lMH,VELEV,VSNR 

C  PUT  NEW  STATE  VECTOR  ANU  ERROR  MATRIX  BACK  INTO  AMTRK  FILE. 

72  CALL  PUTBK (IDENT, STATE*ERROR) 

C 

c  GENERATE  DTDS  FILE  FOR  FIRST  VEHICLE. 

IF(IHAND-2i)  92*91,92 

91  IMANOsn 

C  I0UM2=1 

CALL  Q'JECUR 
CALL  SRIBLU 
RETURN 
C 

c  generate  otus  file  for  second  file. 

92  IF  ( JHANO-20  )  li;i),9S*lUC 

95  JHAND='J 

C  I0UM2=2 

CALL  QUECOR 

call  sribld 

100  RETURN 

ENO 

SUBROUTINE  BEGIN  (C.CT.CC.CCT. IPRT) 

C 
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C  ROUTINE  TO  INITIALIZE  FILTERING  MATRICES  AND  CALCULATION  CONSTANTS, 

C 

DIMENSION  C  ( 1 0  *  1 0  ) »CT ( 1 0 , 1 U  1 •CC(10»10) *CCT(l0»10) 

COMMON  Rll»H12»Hl3»H21*rt22»R23»R3l»R32»R33*ASCL*ANG»XAH*YAH»ZAH 
C 

C  read  in  rotation  matrix 

R11--6.50574B74Q5E-U1 
Rl2-7,59440l7754E-Ol 
R13-1.7175573352E-03 
R2  la-6, 56372 16849E-H 
R22— 5.6341633147E-01 
R23-S,  ;i7J46050lE-0l 
R3l=3.n20o511736E-Ol 
R32a3.2528857063E-Ol 
R33»8.650i9905G5E-0i 
C 

C  SET  VECTOR  DISTANCE  BETWEEN  RADARS 
PI-3. 1415926535 
RAO«2.*PI/360. 

SCL»12. *2. 540005/100. 

RAH»55156.172*SCL 

EAH»-.11119*RAU 

AAH*?20.6a887*RAj 

SEAH«SIN(EAH) 

CEAH-COS (EaH) 

XAH«RAH«CEAh 

YAHaO.O 

ZAHaRAH*SEAH 

ANQaAAH-PI/2. 

ASCL»1. 8737055/1. 25 


DEFINE  FIlTEPING-CONSTANTS  MATRICES. 

C  ■  FILTERING-CONSTANTS  MATRIX 
CT  a  TRANSPOSE  OF  oF  C 
CC  a  IOENTITY-MATRIX  scompliments  of  c 
CCT  a  THAwSPOSE  OF  CC 
DO  10  1-1,10 
DO  9  J* l,lo 
C  ( I ,  J )  =  0 ,, 

9  CC(I,J)»0.C 

10  CONTINUE 

C  ( 1  •  1 )  »0  .-*05 
C (2,2 ) aO ,405 
C(3*3)  a0.4li5 
C (4 • 1 ) >0.625 
C(5»?) -0.625 
C(6,3) -0.625 
C(7, 71*0.500 
C (8,8) *o. 500 
C (9*9) *0.500 
C(10»10)*0.500 
DO  20  1=1,10 
DO  15  J= 1 « 1 0 
IF(I-J)  13,14,13 

13  CC ( I , J) a-C ( I « J) 

GO  TO  15 

14  CC(I,J)»1.0-C(i»J) 

15  CONTINUE 

20  CONTINUE 

DO  55  1=1,10 
DO  54  J-1,1) 

CCT ( I  *  J) -CC ( J* I ) 

54  CT (I  * J)=C ( J*I ) 

55  CONTINUE 
C 

C  PRINT  OUT  TRANSFORMATION  NUMBERS, 
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PHINt  I.ASCL.AInIG.XAH.YAMiZAH 

FORMAT ( A£20 .10) 

RETURN 

end 

subroutine  start  t  icycle»  iprti 

SUBROUTINE  TO  INITIALISE  STATE  VECTORS  AND  ERROR  MATRICES. 

DIMENSION  vECl ( 1 0 ) * VEC2 ( I J ) »ECMl ( 1 0 • 1 0 ) * ECMS ( 1 0  *  1 0 )  _ 

COMMON/HSOS/OUMMYl .VHANOE.VAZlMrt.VELEV.VSNK  .DUMMY?.  Vi IMt » 

1  COMMON/ AMTRK/VEC l»TlMEl«iSll.lS12»I0ll»lUl2»ECMl» 

1VEC2.TIME2.1S21. IS  22 . IU2 1 . ID22 • ECM2 

DOUBLE  PRECISION  TIME»VTImE«VEC1»TIM£1»ECM1*VEC2. TIME2.ECM2 
CONVERT  AMRAD  MEASUREMENTS  TO  HAPDAK  COORDINATES 

CALL  COOR ( VRANU£,VaZIMH,VELEV,RBAR,ABAR,BBAR,1PRT) 

INITIALIZE  STATE  VECTOR  USING  RSDS  NUMBER'S. 

IF ( ICYCLE+2 )  20*30.5 

VEC1 (1)*RBAR 

VEC1 (2)«ABAR 

VEC1(3)»BHAH 

RETURN 

VEC2 (1 >*RtfAH 

VEC2  (2 )  =At)AR 

VEC2 (3) =BBAR 

RETURN 

IF  ( ICYCLE*  1 )  lC.n.15 
VECI  (4)*-lO.*(VECl  (l)-RBAH) 

VEC1(5)*-I0.*(VEC1 (2J-ABAR) 

VECI  (6)  =-m.*  ( VECl  (3)  -BUAR) 

RETURN 

VEC2 (4) s-10.* < VEC2 ( 1 ) -RBAR) 

VEC2 (5 ) *-10  «* • VEC2 (2J-AMAR) 

VEC2 (6) ■-!»•*( VEC2 (3) -ttaAR) 

initialize  status  and  iu  HITS. 

IS11«0 
I S 1 2  *  1 
IS21»0 
IS22»1 
I011«l 
1012*0 
1021*1 
11)22*1 

INITIALIZE  TIMES 

TIME1*VTImE 

TIME2*VTIhE 


VECI ( 7) *0 
VEC2  <7 ) =0 
VECI (8) B0 
VEC2 (8)  a0 
VECI (9) *0 
VEC2 (9) =0 
VECI (10) = 
VEC2 ( l 0 1 8 


,1*RUAR 
.  1  *RB  AH 
.  I*  At!  AH 
. 1«ABAH 
,l*boAR 
,1*BUAR 
vSbR 
vSNR 


INITIALIZE  ERROR  MATRICES  USING  STATE  VECTOR  NUMBERS. 
DO  55  1*1.10 
DO  50  Jsl.lO 
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ecm i ( i , j) =u  .0 

50  ECm2(!«J)=",0 

55  CONTINUE 

ECMl (1,1) =3u.**2 

EC m2 (1,1) a3u.**2 

ECMl  ( 2 , 2  )  s  ( >♦  .  0  / 1  )0>j.)**2 

EC  M2  (2,2)  a  (4.0/1  OiUi  • )  **2 

ECMl(3,3)  =  (4.o/l,jUO.)**2 

EC  M2  (3 ,3 )  s  ( 4 .  o/l  noij . )  **2 

ECMl  (4,4)  =4()0.#£CM  (1*1) 

ECM2 (4,4)s4  0l),*ECM2 (1,1) 

ECMl (5,5) ■400.*tCM  (2*2) 

ECm2(5,5)b4oo.*ECM2<2,2) 

ECMl (6,0) =400.*ECM 1(3,3) 

ECM2(6,6)=400«*ECf»2<3,3) 

ECM1(7»7)*ECM1 (1,1) 

EC M2 (7, 7) sEC M2  (1,1) 

ECMl (6,8)=ECM1 (2,2) 

ECM2 (6 ,d ) sECM2  (2,2 ) 

ECMl (9,9) *ECMl (3,3) 

ECM2 (9 ,9 ) =ECM2 ( 3 ,3 ) 

ECMl (10,1 j) *10,*2 
ECM2(16»lD)sio,*2 
100  CONTINUE 
RETURN 
END 

SUBROUTINE  GETBK  ( IuENf  *  ST ATE, ERROR) 

C 

C  ROUTINE  Tu  GET  INFORMaT ION  BACK  FROM  AMTKK 

c 

DIMENSION  ST  ATE  (If)  .ERROR  (1(1, 10)  , 

1VEC1 (10) tECMl (lo.lo) ,vtC2(ln) ,ECM2( 10,10) 
C0MM0N/AMTRK/VECl,TlMEl,ISll,lS12,lini,lU12,ECi,U, 

1 VEC2, TIME  2*1  S2l»lS22*I  102 1, I022.ECM2* IDUP 1 , 10UM? 

C 

DOUBLE  PRECISION  T  IME,  V  I  IME,VEC1»  T1ME1  ,ECM1 »  VEC2,  T  IME?  ,ECMJ> 
C 

ICOOE  =  '.i 

IF(IDENT-l)  low, 100,200 
100  CALL  SCALE (STATE, vECl , ERROR, ECMl ,1C0DE) 

RETURN 

200  CALL  SCALE (STATE, vEC2,EHRQR, EC M2, ICUUE) 

RETURN 

END 

SUBROUTINE  SETUP  (STATE, DATA, 1PHT) 

C 

C  ROUTINE  To  SET  UP  VECTOR  DATA  «ITH  AMKAC  MEASUREMENTS, 

C 

DIMENSION  STATE(lO) ,OATA(ij) 

COMMON/  RSUS/UUMMY | « VRAikGE *  V A/ IMH  * VELEV , V SNR , QUMM Y2 , V T IME , 

1  IS] , IS2, lul « ID2 

DOUBLF  PRtCISIUN  TIME,  VT  In  E  ,  VEC  l  ,  T  IME  I  ,E  CM1 ,  VEC2 ,  T  IMfc  2.ECR2 
C 

C  define  calibration  numbers  fhom  program  biases, 
oat  A  ARl  ,  »«R2  ,  AR3/')  ,  u  ,  1 ,0  ,  w  .  0/ 

DATA  AU1,aU2,AU3/0. 0,1.0, >1.0/ 

DATA  AVI, AV2,AVJ/).W,1. 0,0.0/ 

DATA  ASNH/f.  .0/ 

c 

C  PERFORM  CuiirdInAIE  TRANSFORMATION  FROM  AMRAU  TO  HAPUAR, 

CALL  COOR ( VPanGE , V a2IMM, VKLEV ,RRR,UUU, VV V , IPRT ) 

C 

C  SET  UP  VECTOR  DATA. 

C  1  =  RANGE ,  2  =  U,  :j  =  V,*,  s  ROOT,  5  »  UCOT,  6  =  VDOT, 

C  7  3  RAnGE  LAO,  «  =  U-L?G  s  g  3  v-LAG  ,  10  =  SNR 

DATA  (  1  )  s Ac  l  ♦aR2«RRR*An.3*VVV 
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DATA  (2)  *AU1*AU2*UI;U*AU3*VVV 
DATA  (3)  =  AVl*AV2*Wv.AV3*UUU 
DATA(4)«STATE(A) 

DATA (5) “STATE (5) 

DATA (6) =STATE (6) 

0ATA«7)*D«TA(1)-STaTE(1) 

DATA (8) “DATA (2) -STATE (2) 

DATA (9) =DaTA (3) -STATE (3) 

DATA ( 1 0 ) =VSNR.ASNR 

RETURN 

END 

SUBROUTINE  COOH ( VR ANGE *  VAZ IMH, VELE V * RRR »UUU* VV V • IPRT  > 

C  ROUTINE  TO  PERFORM  COORDINATE  TRANSFORMATION  F«OM  AMRAD  TO  HAPUAR. 

c 

COMMON  RlifRl2,H13,R21»H22*H23*H31*R32.R33.ASCL.AN6i XAH.YAH.2AM 

IF(IPHT)  20*20.10 
10  PRINT  1 .VHANGE.VAZIMH.VELEV 

20  RAT*VRAN6£ 

AAT»VAZIMH 

EAT=VELEV 

AAT*AAT-ANO 

CAATeCOSUAT) 

SAAT«SIN (AAT ) 

CEaT»COS(EAT) 

SEaT-SIN(EAT) 

xat«rat*ceat*saat 

YAT«RAT»CEAT*CAAT 

zat«rat*seat 

xsave«xat-xah 

ysave«yat-yah 

zsave*zat-zah 

XFT»R11*XSAVE*R12«YSAVE*R13*ZSAVE 

YFT»R21*XSAVE+R22«YSAVt*R23*ZSAVE 

ZFT=R31*XSAVE*R32«YSAVE^W33*ZSAVE 

c 

c  RRR  =  HAPDAR  RANGE  COORDINATE 

RRR  «SORT(XFT*XF  T.YFT-YFT.ZFT-ZFT) 

C 

C  UUU  s  HADAH  U  COORDINATE 

UUU  a-ZFT/RRR 
C 

c  VW  E  HADAR  V  COCRDlNA  ( E 

VVV  s.XFT/RRR 
IF  ( IPRT I  M0.40.3C1 
30  PRINT  1 . RRR . UUU . V V V 

1  FORMAT ( 1H  .4£12,5) 

40  RETURN 

END 

SUBROUTINE  UPDATE  (STaTt, ERROR. DELTA) 

ROUTINE  TO  UPDATE  STATE  VECTOR  ANIJ  ERROR  MATRIX  BY  ONE  PULSE  PERIOD. 

nominal  pulse  period  euuals  o.i  seconds 

DIMENSION  STATE(lU) .EHHOR(IO.IO) 

UPDATE  STATE  VECTOR  USING  DELTA 
RATIOsDELTA/0. 1 

STATE (t) =STATE ( 1) ♦STATE(4)«HATI0 
ST  ATE (2) -STATE (2) *STATE (5) *RAT  10 

st  ate  (3)  estate  (3)  .state  (<>) -ratio 

c 

C  UPDATE  ERROR  MATRIX  USING  DELTA 
DO  10  1*1,3 
DO  9  J=1 ,h 

9  FRROR ( t , J) eERHOR ( t . J) *ERRUR < I .3. J) *  (HATIU-RaT ID) 
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19 

20 


C 

C 

c 

c 

c 

c 


c 

c 

c 


c 

c 

10 


lb 

20 

C 

C 

2no 


C 

300 


25 


26 


CONTINUE 
DO  20  1=1.0 
DO  19  J  =  1 .3 

ERHOR(I.JIaERROR(I,J)*tHR(JR<ltJ*3)*(NATlU*HAT10) 

CONTINUE 

RETURN 

EM) 

SUBROUTINE  COKV£C( STATL.C.OAT A) 

ROUTINE  To  CORRECT  UPUAIEU  STATt  VECTOR  *ITn  MEmSURF.D  DATA. 

STATE  U1EW)  =  SThTE(ULD)  ♦  C*  (  S  T  A  TE  ( ME  ASOHEU ) -S  I  ATE  ( ULD  )  ) 
a  (l  -  C> *3T«TE (OLD!  ♦  C*STATE (MEASURED) 

=  CC^ST  A  TE ( ULD )  ♦  C*ST ATE (MEASUHSED ) 

DIMENSION  STATE(lu) »C(10.10) .DATA(lo) 
STATE<*>«sTATE(*>4C«*»l>*(UATA(l)-STATEm> 

STATE (6) =STATE (5) *C (5.2) * (DATA (2) -STATE  <2) ) 
STATE(0)=STATE(6)*C<6«3)#(DATA(3)-STATE(3)) 

STaTE(!)='5TATE(I)*C<1*1)*<DATA(1)-STATE(1))  , 

STATE (21 =1T ATE (2) ♦C(2i2)*(DATA(2)-STATE(2)) 

STATE (3) =  ST ATE (3) ♦C<3»J) *(UATA(3)-STATE<J) > 

STATE  (7) =STATE ( 7) *C (7*7) * (DATA ( 7) -STATE >7) ) 

STATE (6) = STATE (d) *C (d»e)> * (DATA (8) -STATE (B> ) 

STATE (9)  =  >TATE (9) *C (9tV) * (DATA (9) -STATE (9) ) 

ST  ATE  ( 10)  »STATE  ( li) )  *C  ( 1  0  ♦  10  )  *  (DATA  ( 10  )  -S  TATE  ( l  0  >  ) 

RETURN 

END 

SUBROUTINE  CURMAT (STATEiOATA.ERRORtCtCC»CT  «CCT ) 

ROUTINE  TO  CORRECT  URu A I  El)  ERRUR  COVARIANCE  MAlRIX  wITH  NEASURED  DATA. 

DIMENSION  STATE  (10)  tERROR(lOilO)  tCUOtlO)  tCCU'JtlO)  . 

1DATA  ( 10)  tUll-F  ( 1 '))  tWMA  I  ( 10. 10)  .SMAT  (10. 10)  iTMAT.(  10. 10)  tTVEC  ( 10) 

2.CCT  (10.1  )  tCTdi/tl'*)  tUMAT  (10.10)  t  VMAT  ( 1 0 . 1 0  ) 

FORM  MEASURED  ERROR  COVARIANCE  MATRIX  AND  SIORE  IN  TMaT, 

DO  10  1=1.10 

DlFF  (1)=DaTA(I)-3TaTE(I) 

DO  20  1=1,10 

DU  15  Jsl.lO 

HM AT  ( I  .  J) =0.0 

SMAT  (l.J) =0.0 

TMAT  (I.J)aDlFK  (  I)*!iIFK(  J) 

UMAT ( 1 . J) s 0,0 
VMAT ( I . J) =0.0 
CONTINUE 

DETERMINE  NEW  ESTIMATE  FOR  ERROR  COVARIANCE  MATRIX. 

IF  <  1 )  200.200.33') 

CALL  MULMAT ( SNA r »C . THAT ) 
call  mulm*t (rmat.smat.li ) 

CALL  MULMi.T  (VMAT  tCC. ERROR) 

CALL  MULMmT  (!JMaT  .vmat .CUT  ) 

GO  TO  si 

DO  25  1=1,6 

SM  AT  ( 1  ♦  I )  =C  ( 1 .  I  >  *  T'-lAT  1 1  »  I) 

SMAI  (?♦  I )  =C  (2.2)  *T  -1A  T  (2 .  I  ) 

SMAT  (3 . 1 ) »C (3 , 3 ) *T  |A| (3.1) 

SM  A  T  ( 4  ,  I )  =C  <  4 »  l )  «  M  A  T  (  1 »  I  ) 

SMAT (b.I) =C(5»2)*Tm A T(2. I) 

SMAT (6. 1) =C (6.3) *TMAT lit  I ! 

DO  26  1=7,9 

SMAT  (7. 1 )  =C(7»  7)*T:>1AT  (7.  I ) 

SMAT (h. I )-C (R.o) *T  )AT («» I ) 

SMAT (9. 1 ) =C (9. J ) *TMAT (9. I ) 
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SHAT  ( 10*  10  )  =  C  ( 1  0*  lo )  *  r mat  (  lo  *  li)) 

c 

DO  27  1=1*6 

RMAT  (1*1) =SMAT (I* 1)*CT (1*1) 

RMAT (1*2) =SMAT (1*2) *CT (2*2) 

HMAT (1*3) =SMAT (1*3) *CT (3,3) 
RMAT(I*4)=SMAT(I,1)*CT (1*4) 

RMAT ( I *5) *SM AT ( I *2 ) *CT (2*5) 

27  RMAT(I,6)=SMAT(I*3)#CT<3*6) 

DO  28  1=7,9 

RMAT ( I  •  7 ) »SMAT (1*7) *CT (7*7) 

RMAT (I*8)=SMAT (1*6) #CT (B*8) 

28  RMAT  (1,9)  =SMAT  ( I *9 ) #CT  (9*9 ) 

RMAT ( 1 0  * l  o ) »SMAT ( 1  0 ♦ 1 0 ) *CT  < 1 0  *  1 0 > 

C 

DO  29  1=1*6 

VMAT (1*1) =CC (1*1) *£RRUH (1*1) 

VMAT (2*1) “CC (2*2)aeHRQK(2*I) 
VMAT(3,I)*CC(3*3)*e««0M(3.I) 

VMAT (4,1) *CC(4,1)*EHK0H< 1*1) ♦CC(4*4)*ERR0R(4,1) 
VMaT (5*I)=CC(5*2)*ERRUR(2*I) ♦CC(5,5)#ERR0H(5*I> 

29  VMAT (6, I ) «CC (b,3)*EHR0H(3*I) +CC (6*6) *ERROR (6* l > 
DO  30  1=7,9 

VMAT ( 7 , I ) =CC ( 7 , 7 ) «ERH0« (7.1) 

VMAT (8.1) =CC(H,8)«EH«0R(8* I ) 

30  VMAT(9.I)=CC(9*9)«E«H0R(9,1) 

VMAT ( 10* I ) =CC ( lo* 10> •ERROR (10*1) 

C 

DO  31  1=1*6 

UMAT(I,1)*VMAT(I*1) *CCT (1*1) 

UMAT (I ,2)=VMAT (1*2) *CCT (2,2) 

UMAT  (I,3)»VMAT(I*3) #CCT (3,3) 

UMAT  <  1*4)  =VMAT  ( 1*1  )*CCT  (1.4)  ♦  VMAT  ( I*4)*CCT  (<**4) 
UMAT (1*5) =VMAT ( I*2)*CCT (2,5) +VMAT (1*5) •CCT (b*5) 

31  UMAT(I,6)=VMAT(I*3) *CCT (3*6) ♦ VMAT (I,6)*CCT(6,6) 
DO  32  1=7,9 

UMAT ( I,7)=VMAT( I,7)*CCT(7,7) 

UMAT (I*8)=VMAT(I,8)#CCT(8*8) 

32  UMAT (I*9)=VMaT (1*9) *CCT (9*9) 

UMAT ( I  *  10) =  VMAT ( l « 1 0) *COT (10*10) 

51  DO  60  1=1*10 

DO  55  J=l*10 

55  ERROR(I*J)=HMAT(I*J)*UMAT  <I,J) 

60  CONTINUE 

RETURN 
END 

SUBROUTINE  PUTaM ( I DENT, STATE* ERROR* 1PRT) 

c 

C  SUBROUTINE  To  PRINT  CALCULATED  numbers, 

c 

DIMENSION  SI  ATE ( 1 C ) , ERROR (10*10) *TEMP(10) 
IF(IPRl)  100,100*200 
200  PRINT  1 

PRINT  1*  (STATE ( I ) ,1=1*1  -) 

1  FORMAT ( 1H  *  1 0E12 .5 ) 

DO  10  1=1,10 

10  TEMP(I)=SURT(ABS(ERR0R(1*I) )  ) 

PRINT  1 

PRINT  1,  (TEMP(I) ,1  =  1*10) 

PRINT  1 

PRINT  1,  (  (ERROR ( I  *  J> *J=i*l0>  *1  =  1*10) 

100  RETURN 

end 

SUnHOUT  INt  PU1HK  ( I UEInT  , STATE, ERROR) 

c 

C  ROUTINE  To  Pur  CALCULATED  DATA  BACK  1NTC  AMfRK* 
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c 

DIMENSION  STATE Uu) » ERROR  <10*10)  i 
lVECl(lO)  tCCMi  ( l  (j  t  in)  •  VEC2  ( 10  )  .ECM?UU*10) 

COMMON/AMrRK/VECl, TIME1*IS11.IS12«I011»I012»ECM1, 

1 VEC2. TIRES# IS21 .IS22. 1021, IU22.ECM2 
C 

DOUBLE  PRECISION  TIME, VTlRE»VECl#TIMElfECMl,V£C2, TIMES, ECM? 

c 

1C0DE*1 

IF(IDENT-l)  Id0*100»2j0 
100  CALL  SCALE(STATE»VEC1,ERHuH»ECM1,IC0DE) 

RETURN 

200  CALL  SCALE {STATE *VEC2*EHR0R*ECM2»IC0DE) 

RETURN 

END 

SUBROUTINE  SCALE { STATE » VtC l , ERROR , ECM1 , ICODt ) 

C 

C  ROUTINE  TO  (3EI/PUT  aMhaU  DATA,  WITH  APPROPRIATE  SCALING# 

C 

DIMENSION  STATE ( 10 ) *V£C1 ( 1 0 >  »ERROR ( 10 1 10 ) t ECM1 ( 1 0 • 1 u  > 

DOUBLE  PRECISION  T IME * V T IME , VEC1 . T IME 1 ,ECMi , VEC2 . TIME2 ,ECM2 
IF(ICODE) l.lilOO 
C 

C  SCALE  VELOCITY  FROM  METERS/SEC  TO  METERS/PULSE. 

1  DEL=0.1 

DO  5  I«1»H 
DO  4  JsliUI 

4  E«ROR(  I,J)=ECM1 «I,J) 

5  STATE<I)=VEC1(I) 

DO  3n  i*l,3 

DO  29  J=4,6 

29  ERROR ( I t J) =ERHOR ( I » J) *OEL 

30  CONTINUE 

DO  28  1*4,6 
STATE(I)=STATE(I)«UEL 
DO  27  Ja 1 # 3 

27  EWROR(I.J)«ERROR(I,J)*UEL 
DO  26  Ja4 #6 

26  ERROR ( I*J)=ERR0H(I,J)*<DEL*0EL) 

28  CONTINUE 
HETURN 

C 

C  SCALE  VELOCITY  FHC-t  MET ERS/PULSE  TO  METERS/SEC* 

100  DEL=10. 

DO  115  I  a  1  •  1 o 
DC  114  Js  1  •  1  o 

114  ECM1 ( I , J) aEHROR ( I » J) 

115  VEC1 ( 1 ) -STATE ( I > 

DOI30  I  *  1 »  3 
D0129  Ja4,6 

129  ECM1  (ItJlrtcMl <1, J)*OfcL 

130  CONTINUE 

DO  128  I s4 » tj 

VEC1  t  I ) ®vEC  1  ( I ) *DEL 

D0127  J=l»3 

127  ECM 1  (I.J)aECMl(I,j)#DtL 
00126  J*4,b 

126  ECM1  (ItJ)=ECM) <I,J)*(UtL<*UEL) 

128  CONTINUE 
RETURN 
END 

SUBROUT INt  MULMAT  U»H»0 

c 

C  MATRIX  MULTIPLICATION  ROUTINE 

C  NON-SYMMETRlC  VERSION 

r. 
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DIMENSION  A  ( 1 0 1 1) )  * tt  ( 1 0  *  1  o  )  *  C  ( 1 0  *  1  U ) 
DO  2  I*l»lO 
DO  l  J=i , 1 0 

1  A  ( I  *  J )  =  0  *  'j 

2  CONTINUE 

DO  10  1=1.6 
DO  9  J= 1  *  fa 
DO  8  K=l*6 

SA  VE 1  =B  ( I  *  K ) 

SAVE?=C(K, J) 

IF (SAVE! )  6*8.6 

6  IF ( SAVE2 )  7.H.7 

7  A(I*J)«A(I*J)*5AVEl*SAVE2 

8  CONTINUE 

9  CONTINUE 

10  CONTINUE 

DO  20  1=7,9 
DO  19  J=7 ,9 
DO  18  K=7 *9 

18  A(I*J)=A(I*J)*8(I.K)#C(N»J) 

19  CONTINUE 

20  CONTINUE 

4  ( 1(1.  10)  =6  ( 10*10)  *C  110*10 

HETUKN 

END 
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CORRELATION  PROGRAM  QUECOR 
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Appendix  C 


CORRELATION  PROGRAM  QUECOR 


The  field  test  version  of  the  correlation  algorithm  is  called  QUECOR. 
The  purpose  of  this  appendix  is  to  briefly  discuss  the  theoretical  basis 
for  the  correlation  algorithm,  describe  the  logical  structure  and  opera¬ 
tion  of  QUECOR,  and  present  a  listing  of  QUECOR.  A  more  detailed  dis¬ 
cussion  of  the  theory  and  operation  of  the  correlation  algorithm  was 
presented  in  the  final  report  of  the  Radar  Netting  Phase  II  effort.1 

Also,  a  description  of  QUECOR  and  its  interfaces  with  other  portions  of 

* 

the  software  system  is  contained  in  Ref.  8. 

A .  A  Summary  of  the  Theoretical  Basis  of  the  Correlation  Algorithm 

The  purpose  of  the  correlation  algorithm  is  to  determine  on  request 
whether  an  object  (or  objects)  being  tracked  by  one  radar  is  also  being 
tracked  by  a  second  radar.  It  does  this  by  comparing  a  given  track  from 
one  radar  (assumed  to  be  a  radar  from  which  we  wish  to  hand  over  the 
track)  with  the  track  file  of  a  second  radar. 

The  correlation  algorithm  is  based  on  computing  a  quadratic  function, 
Q,  of  the  difference  between  the  estimated  position  vector  produced  by 
one  tracking  filter  and  one  produced  by  another  tracking  filter,  and  the 
associated  covariance  matrices  for  these  estimates.  This  quadratic 
function,  Q  (hereafter  called  the  correlation  parameter),  is  then  com¬ 
pared  to  a  threshold  to  test  the  hypothesis  that  the  two  tracks  are  of 


*In  Ref.  8,  QUECOR  is  referred  to  as  QUECORR. 
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the  same  object.  In  practice, 
pair  of  subscripts  to 
puted  (i . e . ,  Q  i 
track  i  and  track 
following  sections 


the  correlation  parameter  should  have  a 
the  pair  of  tracks  for  which  it  is  com*- 
correlation  parameter  for  the  pair, 
ipts  will  be  suppressed  in  this  and 
d  to  avoid  ambiguity. 


Let  x  be  the  esu 


late  vector  obtained  from  track  i,  and 


be  the  corresponding  covariance  matrix.  Given  two  state  vectors  obtained 

A  i  A  J 


from  two  tracks,  let  Ax  -  x 

AW  AW 

of  tracks  is  defined  as 


and  C  =  C  +  C  .  Then  Q  for  that  pair 
i  J 


q  =  AxT  C  1  Ax 

Note  that  AxT  is  a  (1  V  3)  matrix,  C_1  is  a  (3  v  3)  matrix,  and  Ax  is 
a  (3  X  1)  matrix.  Thus,  the  product  indicated  by  the  right  hand  side 
of  Eq.  (2)  is  a  (1  X  1)  matrix,  or  a  scalar.  A  nonmatrix  form  of  Eq .  (2) 
can  be  written  if  we  define 


and 


Then,  we  have 


[A^, 

Av 

'ail 

ai2 

ai3 

a 

a 

a„  „ 

21 

22 

23 

-a31 

a32 

a33. 

3 

Q  =  V'  a,  Ax  Ax 
/  j  km  k  m 

k=l 

m=l 


(3; 
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The  parameter  Q  can  be  thought  of  as  the  sum  of  the  squares  of  the  com¬ 
ponents  of  the  position  difference  vector  normalized  by  a  measure  of 
the  expected  dispersion  in  the  corresponding  component  direction. 

Since  the  components  of  the  state  vector  x.1  are  random  variables 
which  are  assumed  to  be  normally  distributed  with  covariance  matrix  C^, 

Q  also  is  a  random  variable  whose  probability  density  function  can  be 
derived.  In  the  case  where  the  mean  value  of  Ax  is  the  zero  vector, 
the  parameter  Q  has  a  chi-square  distribution.  This  corresponds  to  the 
case  where  the  two  tracks  being  compared  are  correlated  or  correspond 
to  the  same  object,  and  no  bias  errors  are  present  between  the  two  track, 
ing  radars.  Due  to  the  normalizing  feature  in  the  parameter  Q,  and  the 
fact  that  in  general  Q  is  computed  from  an  n-long  vector,  the  mean  value 
of  Q  turns  out  to  be  equal  to  n.  The  n  is  called  the  degree  of  freedom, 
and  in  our  case  n  =  3,  so  that  the  mean  value  of  Q  is  3. 

The  chi-square  density  function  is  given  by 


f  2<n.Q> 

X 


(4) 


where  Q  5  0,  and  T(n/2)  is  the  gamma  function,  which  for  integer  argu 
ments  reduces  to  the  factorial  function  [i.e.,  if  n  is  even  then 
T(n/2)  =  (n/2  -  1)!].  For  our  case,  n  =  3,  and  T(3/2)  =  \j v,/ 2,  and  we 

obtain 


f  2<3,Q> 
x 


(5) 


The  function  is  plotted  in  Figure  C-l. 
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When  the  objects  are  uncorrelated,  the  quadratic  function  Q  will 
be  a  sample  from  a  noncentral  chi-square  distribution,  which  has  an 
additional  parameter  called  the  noncentrality  parameter,  \.  The  non¬ 
centrality  parameter  is  a  function  of  the  separation  vector  between  the 
pair  of  uncorrelated  objects.  In  particular,  it  is  the  value  of  the 
quadratic  function  evaluated  at  the  true  separation  vector.  If  the  true 
separation  vector  is  given  by  Az,  the  \  is  given  by 


-1. 

C  Az 


(6) 


The  form  of  this  distribution  in  relation  to  the  chi-square  is  shown  in 
Figure  C-2.  Note  that  when  \  =  0,  Eqs.  (7)  and  (8)  reduce  to  the  chi- 
square  density  functions.  Thus,  the  chi-square  distribution  can  be 
viewed  as  belonging  to  the  more  general  family  of  noncentral  chi-square 
distributions . 

To  summarize,  when  a  value  of  Q  is  computed  for  a  particular  pair 
of  tracks,  it  will  either  be  a  sample  from  a  chi-square  or  noncentral 
chi-square,  depending  on  whether  the  two  tracks  are  correlated  or  not. 

The  correlation  algorithm  applies  a  threshold  hypothesis-testing  approach 
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FIGURE  C-2  NONCENTRAL  CHI-SQUARE  DENSITY  FUNCTION 


to  infer  which  is  the  case.  We  test  the  hypothesis  that  the  tracks  are 
correlated  by  comparing  the  computed  value  of  Q  with  a  threshold  value 
Q  ,  and  accept  the  hypothesis  that  the  tracks  are  correlated  if  Q  is 
less  than  Q  .  At  the  same  time,  we  test  the  alternate  hypothesis  that 
the  tracks  are  uncorrelated  in  the  same  manner  but  accept  the  alternate 
hypothesis  only  if  Q  is  greater  than  Qt<  The  problem  then  is  to  select 
a  Q  such  that  the  probability  of  erroneously  calling  a  correlated  pair 
uncorrelated  (a  Type  I  error)  and  the  probabili  ,y  of  calling  an  uncor¬ 
related  pair  correlated  (a  Type  II  error)  are  both  acceptably  low. 

Obviously,  as  the  true  separation  of  objects  in  a  multiobject  situa¬ 
tion  becomes  smaller  and  smaller,  it  will  become  impossible  to  select  a 
Q  that  meets  the  above  criterion.  We  must  therefore  postulate  some 
minimum  separation  of  objects  in  the  tactical  situation.  As  the  separa¬ 
tion  between  objects  increases,  the  hump  in  the  noncentral  chi-square 
density  moves  farther  to  the  right  in  Figure  C-2  (i.e.,  the  expected 
values  of  Q  become  larger).  This  fact,  that  the  expected  values  of  Q  for 
the  chi-square  and  the  noncentral  chi-square  move  farther  and  farther 
apart  as  the  true  separation  of  objects  increases,  motivates  the  threshold 

decision  rule  discussed  above. 

To  determine  a  value  of  Qt  we  can  first  compute  the  probability 
that  Q  >  Q  for  a  sample  from  a  chi-square  distribution  as  a  function 
of  Q  .  Similarly,  assuming  some  lower  bound  on  the  separation  and  its 
implications  on  a  lower  bound  for  X,  we  can  compute  the  probability  that 
q  <  Q  for  a  sample  from  a  noncentral  chi-square  distribution  as  a  func¬ 
tion  of  Q  .  If  these  results  indicate  that  there  exists  an  interval  of 
values  of  Q  such  that  both  probabilities  are  lower  than  some  selected 
low  probability,  then  any  value  of  Qt  from  this  interval  can  be  selected 

to  meet  the  desired  criterion. 
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In  Ref.  2  a  reasonable  lower  bound  on  \  of  about  50  was  derived, 
based  on  an  assumed  lower  bound  on  the  object  separation  of  about  ten 
times  a  radar's  single  hit  measurement  error  standard  deviation. 

For  this  value  of  the  probability  that  a  Q  from  a  noncentral 
chi-square  distribution  would  be  less  than  24.2  is  0.01.  On  the  other 
hand,  the  probability  that  the  Q  for  a  correlated  pair  of  tracks  would 
be  greater  than  about  11.35  is  also  0.01.  Thus,  any  value  of  Qt  between 
11.35  and  24.2  would  ensure  that  the  probability  of  making  a  correlation 
error  of  either  type  would  be  less  than  or  equal  to  0.01.  (Tables  used 
for  the  calculation  of  these  values  can  be  found  in  Ref.  9  for  the  chi- 
square  distribution,  and  in  Ref.  10  for  the  noncentral  chi-square  dis¬ 
tribution.  ) 

It  should  be  noted  in  addition  to  the  fact  that  the  case  discussed 
above  assumed  a  minimum  separation,  the  estimation  accuracy  increases 
as  more  measurements  are  incorporated  so  that  the  expected  value  of  Q 
for  uncorrelated  objects  should  increase  as  time  progresses,  while  the 
expected  value  of  Q  for  correlated  objects  remains  stationary. 

In  the  implementation  of  any  type  of  threshold  testing,  it  is  useful 
to  obtain  bounds  on  the  value  of  the  tested  parameter.  This  is  true 
since  these  bounds  may  be  much  simpler  to  compute  and  may  obviate  the 
need  for  computing  the  actual  values  of  the  tested  parameter  in  most 
cases.  Thus,  a  net  saving  in  computation  time  may  be  achieved. 

Lower  and  upper  bounds  can  be  established  on  Q  using  the  following 
inequality 

A*T  Ax  AxT  Ax 

<  o  <  — - -  (9) 

U  “  L 
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where  U  is  an  upper  bound  on  the  largest  eigenvalue  of  the  covariance  C, 
and  L  is  a  lower  bound  on  the  smallest  eigenvalue  of  C.  Given  C  we  can 
obtain  U  from 


max 

U  =  /  c  ,  + 

k=l,3  \  kk 


km 


(10) 


m=l 

m/k 


where  c  =  (k,m)  element  of  C.  Similarly  we  can  obtain 
km 


L  = 


min  jc  -V  ic 

k=l,3  j  kk  Lu  km' 
m=l 
m^k 


(11) 


These  bounds  on  Q  are  simpler  to  compute  than  Q  itself  primarily 
due  to  the  fact  that  they  do  not  require  the  computation  of  the  inverse 
of  C  and  the  pre-  and  post-multiplication  of  C  1  by  Ax. 

/■v 

The  correlation  algorithm  theory  discussed  thus  far  has  been  devel¬ 
oped  under  the  assumption  that  there  are  no  significant  uncalibrated 
biases  between  the  two  radars  employed  in  the  handover  process.  With 
a  careful  periodic  calibration  of  the  two  radars,  it  may  be  feasible  to 
reduce  the  uncalibrated  bias  errors  to  a  small  part  of  the  expected 
random  errors.  However,  it  is  expected  that  significant  uncalibrated 
or  residual  bias  errors  may  remain.  As  some  information  on  the  statistics 
of  these  bias  errors  is  available,  a  method  is  desired  to  either  adjust 
the  decision  threshold  or  to  adjust  the  computed  Q  values  to  account  for 
these  bias  effects. 


The  first  approach  to  adjusting  the  threshold  has  been  investigated 
and  reported  in  Refs.  1  and  2.  An  exact  analysis  was  not  feasible,  but 
an  analysis  based  on  conservative  simplifying  assumptions  was  carried 
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out  that  resulted  in  a  rationale  for  adjusting  the  decision  threshold. 

This  method  entails  obtaining  the  eigenvalues  of  C  before  computing  Q, 
and  obtaining  the  ratio  of  the  minimum  eigenvalues  of  C  to  the  largest 
expected  variance  of  the  uncalibrated  bias  errors.  This  ratio  can  then 
be  used  for  a  table  look-up  of  the  proper  Q  threshold. 

This  method  has  the  disadvantage  of  requiring  the  selection  of  a 
new  decision  threshold  each  time  Q  is  calculated  for  each  track  pair 
being  processed. 

The  second  approach  is  to  adjust  the  value  of  the  computed  Q.  This 
can  be  implemented  by  adjusting  the  covariance  C  used  in  computing  Q. 

The  basic  idea  is  to  consider  Ax  as  the  sum  of  an  unbiased  difference 
vector  and  some  bias  vector.  The  covariance  of  the  unbiased  difference 
vector  is  given  by  C,  and  the  covariance  of  the  bias  vector  is  given 
by  B.  B  is  assumed  to  be  known.  If  the  unbiased  difference  vector  is 
independent  of  the  bias  vector,  and  the  bias  is  assumed  to  be  a  sample 
from  a  zero  mean  normal  with  covariance  B,  then  the  covariance  of  Ax 
is  equal  to  C  +  B.  We  can  then  compute  Q  as 

Q  =  AxT  (C  +  B)  1  Ax  .  (12) 

Thus,  when  two  tracks  are  correlated,  the  components  of  the  difference 
vector  Ax  can  be  viewed  as  samples  from  a  zero  mean  multivariate  normal 
distribution  with  covariance  C  +  B.  Q  would  then  be  a  sample  from  a 
chi-square  distribution. 

The  effect  of  adjusting  Q  in  such  a  manner  is  to  decrease  the  com¬ 
puted  value  of  Q  to  compensate  for  the  expected  increase  in  Q  caused  by 
any  residual  bias.  This  implies  that  a  Q  threshold  can  be  selected  before 
a  mission  or  engagement,  based  on  an  analysis  of  the  probability  oi  Type  I 
or  Type  II  errors  as  previously  outlined.  However,  any  estimate  of  a 
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lower  bound  on  the  noncentrality  parameter,  X.,  should  be  properly  ad¬ 
justed  to  account  for  the  increased  covariance  when  B  is  added  to  C. 

Note  that  the  prior  expected  value  of  Q  for  correlated  objects  will  be 
3,  but  the  posterior  expected  value  after  several  Q  computations  for 
correlated  objects  will  approach  some  other  value  depending  on  the  par¬ 
ticular  value  of  the  bias  errors  for  a  given  period  of  operation  of  the 
system.  This  occurs  because  the  bias  errors  are  assumed  to  be  constant 
during  any  typical  continuous  period  of  operation. 

QUECOR  has  been  implemented  such  that  the  covariance  can  be  cor¬ 
rected  as  outlined  above;  however,  the  elements  of  B  are  currently  set 
equal  to  zero  pending  handover  calibration  of  the  two  radars  and  acquisi¬ 
tion  of  statistical  data  on  residual  bias  errors. 

B.  QUECOR  Logic  and  Operation  Description 

QUECOR  is  a  real  time,  field  test  implementation  of  the  correlation 
algorithm  whose  theoretical  basis  has  just  been  discussed.  QUECOR  is  a 
routine  that  is  executed  on  request  whenever  a  handover  of  a  track  from 
one  radar  (AMRAD)  to  another  (HAPDAR)  is  desired.  For  the  field  test 
demonstration,  the  system  was  designed  to  request  handovers  once  every 
two  seconds  from  each  of  two  AMRAD  trackers.  These  requests  were 
scheduled  by  TRANFT,  a  program  described  in  Appendix  B.  The  handovers 
of  the  two  tracks  alternated  at  intervals  of  one  second. 

TRANFT  initiates  the  handover  process  by  calling  QUECOR.  QUECOR 
operates  "open  loop,"  so  that  the  operation  of  all  other  functions  is 
not  affected  by  the  output  of  QUECOR.  TRANFT  continues  the  handover 
process  by  calling  SRIBLD  which,  among  other  functions,  sets  up  the  re¬ 
quest  for  the  first  handover  track  pulse  from  HAPDAR.  The  other  functions 
of  SRIBLD  include  the  initial  building  of  the  two  dedicated  track  in¬ 
stances  in  the  HAPDAR  track  file  and  the  reinitialization  of  the  dedicated 
tracks  with  data  from  the  AMRAD  tracks  whenever  a  handover  is  scheduled. 
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A  tactical  version  of  QUECOR  would  also  determine  whether  or  not  to  con¬ 
tinue  the  handover  process,  based  on  the  results  of  the  correlation 
logic,  and  would  insure  that  a  function  like  SRIBLD  is  called  only  when 
necessary  , 

The  inputs  required  by  QUECOR  are  contained  in  two  data  files, 

AMTRK  and  OTDS  .  AMTRK  contains  the  data  for  the  two  AMRAD  tracks,  and 
OTDS  is  the  track  file  for  HAPDAR .  OTDS  contains  the  track  data  on  the 
two  dedicated  tracks  supporting  the  handover  experiment  and  the  track 
data  on  any  other  HAPDAR  independently  acquired  track. 

A  flow  chart  for  QUECOR  is  contained  in  Figure  C-3,  and  a  listing 
of  the  program  appears  at  the  end  of  this  appendix.  When  QUECOR  is 
called,  various  parameters  are  initialized  and  data  from  one  of  the  track 
data  sets  in  AMTRK  is  loaded  into  a  buffer.  The  initializations  basi¬ 
cally  consist  of  setting  several  threshold  values  and  several  covariance 
correction  terms  to  correct  for  residual  bias  effects.  The  AMRAD  tract 
data  loaded  into  the  buffer  correspond  to  that  track  most  recently  up¬ 
dated.  In  practice  this  results  in  the  alternate  selection  of  each  of 
the  two  AMRAD  tracks.  Also,  at  this  time  QUECOR  records  the  AMTRK  file. 

The  data  loaded  into  the  buffer  consist  of  the  AMRAD  track  state, 
covariance,  and  time  of  validity.  After  the  data  are  loaded,  the  co- 
variance  is  corrected  for  bias  effects  by  adding  in  the  correction  teims. 

QUECOR  next  loads  the  track  data  from  OTDS  into  a  buffer.  These 
data  consist  of  the  state,  the  covariance,  the  time  of  validity,  the 
number  of  hits  and  misses,  the  of f-boresight  direction  cosine  of  the 
estimated  position,  and  a  track  identification  number.  The  state  vector 
is  obtained  :*  n  both  an  (R,  u,  v)  coordinate  system  and  a  radar  face 
(X,  Y,  Z)  cartesian  coordinate  system.  If  the  track- is  a  polynomial 
filter,  the  covariance  is  in  an  (R,  u,  v)  coordinate  system;  if  the 
track  is  a  Kalman  filter,  the  covariance  is  in  the  (X,  Y,  Z)  system. 
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INITIALIZATION 


t 


/  INPUT 

FROM  /! 
TRACK 
AM7 

DATA  / 

kMRAD  / 

FILE,  / 

RK  1 

/  RECORD  / 

/  AMTRK  / 

'  DATA  | 

/  INPUT  DATA  / 

/  FROM  HAPDAR  / 

/  TRACK  FILE,  / 

/  OTDS  / 

DETE 
WHICH  1 
FROM 
TO  COF 

RMINE 

NSTANCc 

AMTRK 

IRELATE 

NOTE:  N  -  number  of  in«tance«  In  OTDS. 


RECORD 

QDATA 


FIGURE  C-3  QUECOR  FLOW  CHART 


FIGURE  C-3  QUECOR  FLOW  CHART  (Continued) 
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CORRELATION 

parameter, 

Q. 


COMPUTE  UPPER 
BOUND  ON 
eigenvalue 
OF  COVARIANCE 
MATRIX 


SET  THE 
CORRELATION 
INDEX,  KC. 
EQUAL  TO  K 


SA  -1853 


FIGURE  C-3  QUECOR  FLOW  CHART  (Concluded) 


These  data  are  obtained  sequentially  for  each  instance  in  the  OTDS  file 
and  are  processed  before  the  next  instance  is  obtained.  An  instance  in 
the  OTDS  corresponds  to  a  separate  track.  At  this  point  QUECOR  records 
the  OTDS  instance. 

The  processing  beyond  this  point  is  repeated  for  each  pair  of  tracks, 
consisting  of  the  previously  selected  AMRAD  track  and  currently  loaded 
HAPDAR  track  . 

Since  the  two  times  of  validity  for  the  two  tracks  do  not  generally 
coincide,  the  HAPDAR  state  is  updated  to  the  time  of  validity  for  the 
AMRAD  track.  During  this  process,  the  difference  vector  between  the  two 
state  vectors  is  obtained.  Also  during  this  process,  a  coarse  screen¬ 
ing  takes  place  as  each  component  of  the  difference  vector  is  computed. 
This  coarse  screening  consists  of  a  gross  check  of  each  of  the  components 
of  the  difference  vector.  If  any  component  is  so  large  that  the  marginal 
probability  of  the  objects  being  correlated  is  sufficiently  small,  we  can 
infer  that  Q  will  exceed  the  threshold  and  there  is  no  need  to  actually 
compute  the  value  of  Q.  When  this  happens,  a  flag  for  the  current  HAPDAR 
track  being  processed  is  set  to  -3,  processing  for  the  current  track  pair 
is  terminated,  and  the  next  OTDS  instance  data  is  loaded  into  the  buffer 
and  processed.  Derivation  of  appropriate  thresholds  for  the  coarse 
screening  was  to  have  been  accomplished  based  on  experience  with  the 
correlation  algorithm.  This  was  not  accomplished  due  to  the  paucity  of 
good  experimental  data. 

Should  the  processing  pass  the  coarse  screening  tests,  it  is  next 
determined  whether  a  polynomial  or  Kalman  track  is  being  processed. 

In  either  case,  the  HAPDAR  covariance  is  updated  to  the  AMRAD  time  and 
the  sum  of  the  two  covariances  is  obtained.  However,  if  we  have  a 
Kalman  filter,  the  AMRAD  covariance  must  first  be  transformed  to  the 
(X,  Y,  Z)  coordinate  system,  as  must  the  difference  vector  previously 
obtained . 
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The  next  step  in  QUECOR  processing  is  to  apply  a  second  level  of 
screening,  called  prescreening.  At  this  level,  a  lower  bound  on  Q  is 
computed  using  Eqs.  (9)  and  (10).  Again,  should  this  lower  hound  he  greater 
than  the  threshold,  there  is  no  need  to  actually  compute  Q.  When  this 
happens,  the  flag  is  set  to  -2,  processing  for  the  current  track  pair  is 
terminated,  and  the  next  OTDS  instance  data  is  loaded  into  the  buffer 
and  processed. 

Should  the  processing  pass  the  prescreening  test,  the  value  of  Q 
is  computed  using  Eq.  (2).  At  this  point,  if  Q  exceeds  the  threshold, 
the  flag  is  set  equal  to  -1;  otherwise  the  flag  is  set  equal  to  0.  Also, 
a  correlation  counter  is  stepped  up  to  count  the  number  of  correlations 
for  the  handed-over  track,  and  the  identification  number  of  the  corre¬ 
lated  OTDS  track  is  saved.  This  completes  the  processing  for  the  current 
track  pair,  and  the  next  OTDS  instance  data  is  then  loaded  into  the 
buffer  and  processed. 

The  above  processing  continues  until  all  instances  in  the  OTDS 
file  are  exhausted.  When  this  finally  occurs,  the  output  data  that  is 
contained  in  the  data  file,  QDATA ,  is  recorded. 

QDATA  contains  the  following: 

(1)  An  identification  number  for  the  AMRAD  track  just  processed 
(either  1  or  2  for  the  first  or  second  AMRAD  track) . 

(2)  The  correlation  time  (corresponds  to  the  AMRAD  track  data 
time  of  validity) . 

(3)  The  number  of  HAPDAR  tracks  that  correlate. 

(4)  The  index  for  the  array  of  HAPDAR  track  identifiers  that 
corresponds  to  the  track  that  correlates.  (In  case  more  than 
one  correlates,  the  index  will  be  for  the  last  track  to 
correlate .) 
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(5)  An  array  of  HAPDAR  track  identifiers.  (These  correspond  to 
addresses  and  serve  as  unique  identifiers.) 

(6)  An  array  of  numbers  corresponding  to  the  identifier  array 
that  give  the  total  number  of  track  pulses  sent  out  for  each 
HAPDAR  track.  (These  numbers  serve  to  identify  when  a  HAPDAR 
track  is  purged  and  a  new  track  is  initiated  with  the  same 
identifying  address.) 

(7)  An  array  of  Q  values  computed  during  the  processing,  (These 
entries  are  either  the  lower  bound  for  Q,  the  calculated 
value  of  Q,  or  when  a  track  pair  is  coarse-screened ,  an 
arbitrary  number  of  1,000,000.) 

(8)  An  array  of  flags  to  indicate  the  correlation  result  for  each 
track  pair. 

Currently  QUEC0R  is  set  up  to  process  up  to  25  HAPDAR  tracks  and 
2  AMRAD  tracks . 

At  this  point  QUECOR  processing  returns  control  of  the  CPU  to 
TRANFT,  which  immediately  calls  SRIBLD . 

C  .  QUECOR  Execution  Time 

Timing  runs  were  made  on  the  CDC  6400  at  SRI  to  determine  the  exe¬ 
cution  time  of  QUECOR,  with  the  following  results. 

When  processing  a  given  pair  of  tracks  (one  from  each  of  two  radars), 
three  possible  paths  may  be  executed  within  QUECOR  when  the  tracks  are 
uncorrelated.  The  decorrelation  may  be  determined  by  coarse  screening, 
by  prescreening,  or  by  actual  computation  of  the  correlation  parameter, 

Q.  Coarse  screening  entails  testing  the  estimated  range  and  angle 
separation  against  a  threshold.  Prescreening  entails  computing  a  lower 
bound  on  Q  and  testing  against  the  Q  threshold.  Finally,  if  these  two 


144 


tests  are  passed,  the  value  of  Q  is  computed  and  tested  against  the 
q  threshold.  When  the  pair  of  objects  are  correlated  only  one  path  is 
followed,  namely  the  computation  of  Q  path.  Thus,  execution  times  will 
be  a  function  of  the  number  of  times  each  type  of  path  is  followed. 

In  addition  there  will  be  some  overhead  costs  in  time  due  to  various 
initializations  and  other  computations  that  are  performed  only  once  each 
time  QUECOR  is  called.  A  part  of  this  overhead  cost  depends  on  whether 
a  state  and  covariance  coordinate  transformation  is  required.  This 
requirement  is  a  function  of  whether  any  of  the  tracks  are  Kalman 
filtered.  If  there  is  at  least  one  Kalman  filter  then  the  transformation 

is  required . 

To  find  the  execution  time  let  the  following  definitions  hold, 
k  =  number  of  decorrelations  by  coarse  screening 
p  =  number  of  decorrelations  by  prescreening 

n  =  number  of  decorrelations  and  correlations  by  Q  calculation 
s  =  0  or  1  (0  implies  no  Kalmans  and  1  implies  at  least  one  Kalman) 
t  =  QUECOR  execution  time  in  milliseconds. 

The  executiei  >  can  be  obtained  from  the  following  equation, 

,74k  +  0 . 93p  +  1 ,31n  +  0.62s  .  (13) 

As  .isider  the  case  where  there  are  no  Kalmans,  there 

are  five  track  pairs  to  be  processed,  and  the  object  spacings  are  such 
that  n  =  1,  p  =  2,  and  k  =  2;  then  we  find  that  t  =  5.4  ms.  If  there 
is  at  least  one  Kalman,  then  t  =  6.02  ms.  In  a  worst  case,  where  s  =  1, 
n  =  5.  and  both  k  and  p  are  equal  to  zero,  we  obtain  t  =  7.92  ms. 
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Only  an  approximate  estimate  of  the  execution  time  of  QUECOR  on 
the  IBM  360/65  at  HAPDAR  was  made  during  the  real  time  system  develop¬ 
ment.  This  was  for  a  case  where  n,  as  def  bove,  was  equal  to  3. 

and  k,  p,  and  s  were  equal  to  zero.  The  exeeuiion  time  estimate  was 
4.5  ms.  Using  Eq .  (13),  we  obtain  4.68  ms.  Thus,  it  appears  that 
execution  times  on  the  CDC  and  IBM  machines  are  comparable. 
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A  LISTING  OF  SUBROUTINE  QUECOR 
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SPECIAL  SEARCH  PROGRAM  SSERCH 


Appendix  D 


SPECIAL  SEARCH  PROGRAM  SSERCH 

SSERCH  is  a  real  time,  field  test  algorithm  that  generates  a  series 
of  beam  pointing  directions  and  range  gates  required  for  HAPDAR  to  search 
a  volume  on  special  request.  This  might  be  the  shadowed  volume  behind 
a  nuclear  fireball  that  temporarily  blocks  out  part  of  another  radar's 
search  volume  (in  our  case  AMRAD) .  The  purpose  of  this  appendix  is  to 
briefly  describe  the  logical  structure  and  operation  of  SSERCH,  and  to 
present  a  listing  of  SSERCH. 

SSERCH  was  installed  in  the  tactical  function  library  in  the  IBM 
360/65  at  the  HAPDAR  facility.  SSERCH  was  never  integrated  into  the 
PHSD  system  due  to  the  priority  on  the  handover  and  correlation  software 
integration  and  testing  and  subsequent  delays  in  achieving  that  task. 

Thus,  SSERCH  has  never  been  validated  in  real  time  operation. 

SSERCH  was  meant  to  be  executed  periodically,  once  per  second, 
whenever  QUECOR  is  executed.  The  inputs  required  by  SSERCH  are  contained 
in  two  data  files,  AMTRK  and  SSDATA.  AMTRK  contains  the  two  AMRAD  track 
data  sets,  and  SSDATA  contains  the  results  in  terms  of  hits  or  misses 
for  the  previously  requested  search  beams.  SSDATA  also  contains  the  out¬ 
put  data  of  SSERCH,  which  consists  of  the  requested  search  beam  pointing- 
information. 

SSERCH  assumes  that  the  desired  search  volume  consists  of  the  region 
in  the  shadow  of  a  hypothetical  fireball  of  a  fixed  radius  located  at  a 
range  equal  to  a  fixed  distance  in  front  of  the  handed  over  state  vector 
point  obtained  from  AMTRK.  The  hypothetical  fireball  is  assumed  to  lie 
on  the  linc-of-sight  from  AMRAD  to  the  handed  over  point,  and  the  conical 
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shadow  region  is  defined  relative  to  AMRAD.  The  search  volume  is  assumed 
to  extend  from  the  front  edge  of  the  fireball  to  a  maximum  distance  be¬ 
hind  the  fireball. 


A  flow  chart  for  SSERCH  is  contained  in  Figure  D-l.  When  SSERCH  is 
called,  it  first  loads  data  from  AMTRK  into  s.  buffer.  The  data  obtained 
consist  of  the  position  components  (R,  u,  v)  of  the  first  AMRAD  track. 
SSERCH  then  computes  the  direction  cosines  for  the  handed  over  point  with 
respect  to  AMRAD,  using  the  following  vector  equation; 


T 

e 

~A 


(14) 


where 


% 


=  [u,  v,  w] 


(15) 


w 


(16) 


T 

x  =  transpose  of  the  vector  locating  AMRAD  relative  to 
~AH 

HAPDAR  in  HAPDAR  face  centered  cartesian  coordinates 


Next,  the  range  and  the  direction  of  the  fireball  relative  to  HAPDAR  are 
determined  using  the  relationships 


R 


1 


(17) 


and 


^Hl 


(18) 
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FIGURE  D-1  SSERCH  FLOW  CHART  (Concluded) 


where 


AR  =  the  assumed  distance  of  the  fireball  in  front  of  the 
handed  over  point  relative  to  AMRAD. 

The  subscripts  "l"  indicate  that  these  are  the  pointing  parameters  for 
the  first  search  beam. 

The  maximum  search  range  required  from  IiAPDAR  is  then  computed, 
using  the  equation 


R 

m 


-I-  ARe 


(19) 


Here  we  assumed  for  the  field  tests  that  the  maximum  search  range  rela¬ 
tive  to  AMRAD  is  AR  behind  the  handed  over  point.  Next,  the  maximum 
shadow  tube  radius  created  by  the  fireball  ut  the  maximum  search  range 
is  determined: 


r  =  (R  +  2AR)  r  /R  (20) 

FM  A  F  A 

where 


r  =  assumed  fireball  radius. 

F 

Using  R  and  e  as  starting  points,  SSERCH  successively  computes 
1  r*Hl 

beam  pointing  parameters  for  a  succession  of  up  to  nine  beams,  which 
cover  the  desired  search  volume.  These  beam  positions  are  determined  so 
that  they  sweep  along  the  line-of-sight  from  AMRAD  to  the  handed  over 
point  between  the  two  range  limits.  Figure  D-2  shows  schematically  the 
various  beams  and  range  gates  in  the  plane  containing  AMRAD,  HAPDAR,  and 
the  AMRAD  line-of-sight.  Figure  D-3  shows  schematically  how  the  range 
gate  limits  are  determined. 


Rl^il 


-  x. 


VAH 


(21) 
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Ith  BEAM 
CENTERLINE 


FIGURE  D-3  RANGE  GATE  GEOMETRY 


As  each  beam  is  generated,  SSSRCH  determines  if  R  is  exceeded,  and 

m 

if  so,  a  flag  is  set  to  indicate  that  the  last  beam  is  being  generated. 
Next,  SSERCH  determines  if  the  beam  is  within  the  maximum  of f-boresight 
limits  for  HAPDAR.  If  not,  then  SSERCH  determines  if  any  subsequent 
beams  might  fall  within  the  of f-boresight  limits.  If  all  subsequent 
beams  are  predicted  to  fall  out  of  the  of f-boresight  limits,  no  further 
beams  are  generated,  and  the  processing  proceeds  to  the  final  operations. 
When  this  happens,  a  flag  is  also  set  to  indicate  that  at  least  some  part 
of  the  requested  search  volume  falls  out  of  limits.  If  subsequent  beams 
are  expected  within  of f-boresight  limits,  SSERCH  next  checks  the  previ¬ 
ously  set  flag  to  determine  if  the  current  beam  was  to  be  the  last.  If 
so,  SSERCH  proceeds  to  the  final  operations.  Otherwise,  the  next  beam 
pointing  parameters  are  determined. 

If  the  current  beam  being  processed  falls  within  the  HAPDAR  off- 
boresight  limits,  then  SSERCH  computes  the  range  gate  parameters  for  the 
beam.  The  range  gates  are  determined  in  terms  of  the  pulse  arrival  times 
after  transmission  by  the  following  equations: 


2R 

Imin 


/v 


(22) 


2R  /v 
I  max 


where 


v  =  velocity  of  light 

R_  .  =  (Rt  sin  9  cos  cp  -  r  tan  8)/sin(0-cp)  (24) 

Imin  I  FM 

R  =  (R  sin  9  cos  cp  +  r  tan  9)/sin(0-cp)  (25) 

I max  I  FM 

cp  =  cp  / (2w  )  (26) 
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at  V  *  4  ■  '  V  ml-'  -  ■  -rV'  v.l 


_ 


cp  =  boresight  beamwidth  of  HAPDAR 

th 

w  =  oif-boresight  direction  cosine  for  the  I  beam 

I 

0  =  angle  between  the  AMRAD  line-of-sight  and  the 

centerline  of  the  I ^  beam. 


The  angle  9  is  given  by 


cos 


e 

Mil 


(27) 


After  the  range  gates  are  computed  for  the  I  beam,  SSERCH  deter' 
mines  if  the  last  required  beam  has  been  computed.  If  so,  it  proceeds 
to  the  final  operations;  if  not,  it  computes  the  next  beam  pointing 


parameters. 


Successive  beam  pointing  directions  are  determined  in  u-v  space, 

since  in  this  space  the  beamwidth  is  represented  by  a  constant  diameter 

circle.  Figure  D-4  shows  how  the  next  beam  is  positioned.  Based  on  this 

positioning  scheme,  SSERCH  next  computes  the  distance,  D,  along  the  line- 

"tlr 

of-sight  (from  AMRAD)  from  the  I  to  the  (1+1)  beam.  D  is  given  by 


2  .  2  ,  ,1/2 

D  =  b/a  +  (b  /a  +  c/a) 


(28) 


where 


«s2 

a  =  (eA(l)  -  eHI^>  cos  9) 

+  (e. (2)  -  e„T(?)  cos  9> 
A  Hi 

2 

-  0.1875  Sin  cp 

o 

2 

b  =  0,1875  sin  cpQ  cos  6  Rj 


(29) 


(30) 
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FIGURE  D-4 


SEARCH  BEAM  PACKING  IN  u-v  SPACE 


2 


(31) 


2 

c  =  0.1875  sin  cp  R 
o 

The  beam  pointing  parameters  are  then  computed  from 

2-|l/; 

R  =  [r  2  +  2 DR  cos  6  +  D  | 

i+i  L  i  1  J 

Sh(i+i)T  =  (V-mr  +  ^')/Rm 

The  processing  cycles  back  at  this  point  to  the  determination  of  whether 
this  beam  will  be  the  last  or  not.  The  cycle  is  repeated  until  all  re¬ 
quired  beams  that  are  feasible  are  generated,  or  until  nine  beams  have 
been  generated,  whichever  occurs  first. 

SSERCH  then  proceeds  to  the  final  operation,  which  consists  of  se¬ 
lecting  the  desired  IF  attenuation  level  (0  to  63  dB),  the  frequency 
number  (0,  1,  ...,  7),  and  the  RF  amplifier  state  (0  =  in,  1  =  no  preamp, 

2  =  30  dB  pad,  3  =  open),  and  storing  these  data  in  SSDATA .  SSERCH  then 
records  SSDATA,  which  contains  the  results  of  the  previous  search  request, 
and  the  pointing  information  for  the  new  search  request.  These  data  con¬ 
sist  of: 

(1)  The  minimum  search  range 

(2)  The  direction  cosine  of  the  search  beam  relative  to  the  vertical 
axis  in  the  array  face,  u 

(3)  The  direction  cosine  of  the  search  beam  relative  to  the  hori¬ 
zontal  axis  in  the  array  face,  v 

(4)  The  minimum  pulse  arrival  time 

(5)  The  maximum  pulse  arrival  time 

(6)  An  IF  attenuation  level 

(7)  A  frequency  index 

(8)  An  RF  amplifier  state  index 

(9)  Elements  of  the  hit/miss  index  array  reset  to  -1. 


(32) 

(33) 
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The  hit/miss  array  is  a  9  by  10  array  whose  rows  correspond  to  each 
requested  beam  position,  and  whose  columns  correspond  to  the  number  of 
search  pulses  transmitted  in  a  given  beam  position  since  the  last  special 
search  request.  An  entry  of  -1  in  an  element  of  this  array  means  that 
no  radar  beam  was  formed  or  transmitted,  0  means  no  hit  or  an  invalid  hit 
was  obtained,  1  through  5  means  1  through  5  hits,  respectively,  were  ob¬ 
tained,  and  6  means  more  than  5  hits  were  obtained.  Entries  into  this 
array  are  made  by  the  search  radar  return  processing  function. 

This  completes  SSERCH  data  processing,  and  control  is  returned  to 
the  calling  routine. 
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A  LISTING  OF  SUBROUTINE  SSERCH 


00000? 

000002 

000002 

000002 

000002 

000002 


000002 

000004 

000005 

000007 

000010 

000012 

000013 

000015 

000016 

000020 

000021 

000022 

000023 

000025 

000027 

000032 

000033 

000035 

000037 

000041 

000043 

000044 

000044 

000045 

000050 

000052 

000054 

000056 

000056 

000063 

000065 

000067 

000071 

000072 

000074 

000076 

000100 

000107 

000110 

000111 

000112 

000115 

000120 


SUBROUTINE  SSERCH 

COMMON/ AMTRK/STl <9> . SI t Tl , Si  1 ,S21 1 1 1 1 . 121 ,ERR1 < 1 n , 10 > ,ST2(9>, 

1  S2'T2'S12»S22'I12«I?2tERR2U0'l0) 

DOUBLE  PRECISION  ST1 ,S1 ,T1 .ERR1 ,ST2.S2»T2,ERR2 
INTEGER  Sll tS?l iS12*S22 

COMMON/SSDATA/OATA (6,91 #IDATA<2«9) • IHI T  < 10*9) 

DOUBLE  PRECISION  TiDATA 
DIMENSION  STATE  <6) 

£•••«  c  .  VEL.  OF  LIGHT  (MRS) .  FBR  ■  FIREBALL  RAQIUS  <m> ,  (XAH# YAH.ZAH) a 

c****  amrao  location  in  hapqar  face  centered  cartesian  coordinates  «m, 

C#**«  RAD*RaD>*  DR  ■  RANGE  INTERVAL  ABOUT  HANDOVER  POInT  FOR  SEARCH  <M) • 
C****  ANO  BW  a  HAPDAR  BEAMWIDTH  (RAD> 

C  ■  299792880,0 
FBR  a  1000,0 
XAH  •  6393,9 
YAH  a  10937,27 
ZAH  ■  11050.71 
DR  ■  20000,0 
WTH  >  0.500 
BW  >  0.029 
SBWSQ  •  0.75*BW*BW 
IFLAG  ■  0 
KFLAG  >  0 
N  a  0 
TT1  a  Tl 
TT2  a  T2 

IF  (TT2  ,GT ,  TT1 )  GO  TO  25 
IOENT  a  1 
T  «  Tl 

STATE ( 1 )  a  STl(l) 

STATE<2>  a  ST1 (2) 

STATE (3)  a  ST1 (3) 

GO  TO  35 
25  CONTINUE 
IOENT  a  2 
T  a  T2 

STATE (1)  a  ST2  ( 1 > 

STATE (2)  a  ST2I2) 

STATEO)  a  ST2  (3) 

35  CONTINUE 

w  a  ABS (1,0  -  STATE<2)«STATE(?)  .  STATE (3) *STATE (3) ) 

W  a  SORT (W) 

U  a  STATE(l)»sTATE(2) 

V  a  STATE<1)*STATE«3) 

W  a  ST  ATE  < 1 ) *W 

EXA  a  u  -  XAH 
EYA  a  y  .  YAH 
FZA  a  w  -  ZAH 

RA  a  SQRT(EXA»EXA  ♦  EYA*E7A  .  EZA*EZA) 

FXA  a  EXA/RA 
FYA  a  EYA/RA 
EZA  a  EZA/RA 
U  a  U  -  OR*EXA 

V  a  V  -  DR*EYA 
W  a  W  -  DR*E7A 
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000122 

000130 

000131 

000132 

000133 

000134 

000136 

000141 

000144 

000147 

000156 

000163 

000165 

000167 

000171 

000174 

000177 

000205 

000207 

000212 

000214 

000216 

000222 

000226 

000230 

000232 

000235 

000237 

000241 

000241 

000241 

000245 

000251 

000254 

000257 

000301 

000306 

000310 

000313 

000315 

000317 

000321 

000323 

000323 

000335 

000340 

000343 

000345 

000351 

000353 

000354 

000355 

000356 

000361 

000364 

000366 


R  ■  SORT  <U*U  ♦  V«*V  *  W*W) 

U  ■  U/R 

V  »  V/R 

W  >  W/R 

WOLD  >  W 

OR2  ■  2#DR 

PU  •  R*U  ♦  DR2*EXA 

RV  ■  R*V  ♦  DR2*EYA 

PW  ■  R*W  ♦  0R2*EZA 

PMAX  >  SQRT(RU*RU  ♦  RV*RV  ♦  RW*RW> 

TR  •  FBR»(RA  ♦  DR) / (RA-  OR) 

PMX  ■  RMAX  ♦  TR 
RMN  ■  R  -  1 «5*TR 

10  N  ■  N  ♦  1 

IF  <R  .GT.  RMAX)  KFLAG  ■  1 
IF  < W  ,LT,  WTH)  GO  TO  20 
COSTH  a  U*EXA  ♦  V»EYA  ♦  W*EZA 
THETA  ■  ACOS (COSTH) 

BWMAX  a  BW/(2*W) 

SINTH  a  SIN(THETA) 

COSB  >  COS(BWMAX) 

SINTHP  ■  SIN(THETA  ♦  BWMAX) 

SINTHM  a  SIN(THETA  -  BWMAX) 

RRl  «  R*SINTH*COSB 
RR2  «  TR«SINTH/C0STH 
PI  »  (RRl  -  RR2) /SINTHP 
IF  ( R 1  .LT.  RMX)  GO  TO  15 
N  ■  N  -  1 
GO  TO  50 

15  CONTINUE 

IF  <R1  .LT.  RMN)  R1  a  RMN 

OATA ( 1 «N)  ■  R1 

R2  a  (RRl  ♦  RR2) /SINTHM 

IF  (R2  .GT.  RMX)  R2  a  RMX 

0ATA(*,N)  ■  2*OAT A ( 1 »N) /C 

DATA (5.N)  ■  ?*R2/C 

DATA (2, N)  ■  U 

DATA (3.N)  ■  V 

DATA (6»N)  a  0.0 

IDATA(ltN)  ■  0 

IDATA (2»N)  ■  0 

IF  (N  ,EQ,  9)  GO  TO  40 

GO  TO  30 

20  IP  (MOLD  .OF .  WTH  .OR.  WOLD  .GT.  W)  GO  TO  40 

30  IF  (KFLAG  .GT.  0)  GO  TO  50 
A21  *  EXA  -  U«C0STH 
A22  ■  EYA  -  V*COSTH 
A2  ■  A21*A21  4  A22*A2?  -  SBWSO 
A 1  ■  P*C0STH#S8WSQ 
AO  ■  P<*R*SBWSfl 
A1  ■  A1/A2 
AO  «  A0/A2 

OT  ■  ABS ( A 1  *  A 1  4  AO) 

OT  ■  A1  4  SORT (OT) 

POLO  ■  R 

R  •  ABS(R*R  4  2*DT*R*C0STH  4  0T*DT) 
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000374 

R  ■  SORT (R) 

000377 

II  «  (ROLO*U  ♦  DT*EXA)/R 

000403 

V  «  <ROLD*V  «  DT«*EYA)/R 

000406 

WOLD  •  W 

000410 

W  ■  A8S<1,0  -  u«u  -  V*V) 

000414 

W  ■  SORT (W) 

000417 

60  TO  10 

000417 

40 

IFLAQ  •  1 

000420 

50 

CONTINUE 

000420 

IMAX  ■  N 

00042? 

DO  60  I  «  1*9 

000423 

no  6o  j  ■  1*10 

000424 

60 

IHITIJ.I)  -  -1 

OATA  RECORDING  STATEMENT 

c**** 

IMPLEMENTATION. 

000435 

RETURN 

000436 

END 
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PHSD/SRI  HANDOVER  SOFTWARE  INTERFACE 

The  various  interfaces  among  the  SRI  handover  functions,  the  various 
data  files,  and  other  PHSD  tracking  functions  are  shown  in  Figure  E-l . 

The  SRI  handover  functions  consist  of  VPAS ,  TRANFT.  QUECOR,  and  SRIBLD , 

Other  interfacing  PHSD  functions  include  KRM,  ARRP,  ARR,  DTTSRI ,  and 
WLC .  The  purpose  of  each  of  these  functions,  the  data  files  they  access, 
and  the  rolling  sequence  will  be  briefly  described  to  indicate  how  the 
SRI  handover  software  integrates  with  the  PHSD  software.  (For  a  more 
detailed  description  of  the  PHSD  software  see  Refs.  4  and  11). 

As  raw  AMRAD  data  are  received  over  the  AMRAD  link  to  HAPDAR,  they 
are  loaded  into  the  RSDS  data  file  by  VPAS  .  VPAS  essentially  provides 
the  function  of  loading  the  data  from  the  PAS  Return  Buffer  into  the  RSDS 
data  file  after  converting  the  range  time  to  PHSD  mission  time  and  apply¬ 
ing  a  correction  of  -23  dB  to  the  SNR  measured  by  AMRAD.  Right  after 
this  is  accomplished  TRANFT  is  executed. 

The  function  of  TRANFT  is  to  obtain  the  data  from  RSDS,  convert 
them  to  HAPDAR  coordinates,  and  fit  them  with  an  appropriate  filtering 
algorithm.  TRANFT  loads  the  filtered  data  into  the  AMTRK  data  file. 

AMTRK  contains  the  filtered  state  vector,  covariance  matrix,  time  of 
validity,  SNR,  and  status  and  identification  information  for  the  two 
AMRAD  track  channels.  TRANFT  also  determines  when  it  is  time  to  request 
a  handover  and  correlation  test.  It  accomplishes  this  by  calling  QUECOR 
and  SRIBLD. 

The  present  version  of  TRANFT  is  set  up  to  request  a  handover  once 
every  second  on  alternately  the  first  and  second  AMRAD  track.  New  data 
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FIGURE  E-1  PHSD/SRI  HANDOVER  SOFTWARE  INTERFACE  DIAGRAM 


come  in  to  RSDS  and  TRANFT  at  a  rate  of  20  per  second .  This  corresponds 
to  a  data  rate  of  10  per  second  per  AMRAD  track.  Thus,  TRANFT  is 
executed  20  times  per  second,  but  calls  QUECOR  and  SRIBLD  only  once  per 
second.  At  the  times  when  TRANFT  does  not  request  a  handover,  control 
of  the  CPU  is  returned  to  BMDOS . 

The  handover  process  is  initiated  when  TRANFT  calls  QUECOR.  The 
function  of  QUECOR  is  to  compute  the  value  of  the  correlation  parameter, 
Q,  for  all  track  pair  associations  consisting  of  the  AMRAD  track  to  be 
handed  over  and  each  of  the  HAPDAR  active  tracks,  A  threshold  criterion 
is  applied  to  Q  to  determine  whether  the  AMRAD  track  is  correlated  with 
any  of  the  HAPDAR  tracks,  and  if  so,  with  which  one.  In  a  tactical 
situation  a  decision  might  be  made  at  this  point  whether  or  not  to 
continue  the  handover  process.  For  the  field  test  version  of  QUECOR, 
the  handover  is  attempted  regardless  of  the  results  of  QUECOR  data 
processing . 

In  order  to  compute  each  value  of  Q,  QUECOR  obtains  the  filtered 
track  data  for  the  AMRAD  track  to  be  handed  over  from  AMTRK ,  and  the 
filtered  track  data  for  each  HAPDAR  track  in  the  OTDS  data  file.  The 
OTDS  data  file  is  a  variable  length  or  volatile  file  that  contains  the 
track  data  for  all  of  the  HAPDAR  active  tracks.  This  includes  two 
special  dedicated  tracks  that  can  never  be  purged  once  they  are  built. 
These  two  dedicated  tracks  are  employed  in  the  SRI  handover  experiments. 
Each  instance  in  the  OTDS  corresponds  to  a  track  channel .  The  instances 
contain  the  state  vector,  the  covariance  matrix,  the  time  of  validity, 
and  other  information  on  each  track.  The  results  of  the  correlation 
processing  of  QUECOR  are  loaded  into  a  data  file  called  QDATA .  After 
QUECOR  processing  is  completed,  control  is  returned  to  TRANFT  which 
immediately  calls  SRIBLD. 


175 


The  functions  of  SRIBLD  are  to  initially  build  the  two  dedicated 
track  instances  in  the  OTDS,  reinitialize  the  appropriate  dedicated  OTDS 
instance  with  data  from  one  of  the  AMRAD  tracks,  and  order  a  track  pulse 
transmission  for  that  track.  Thus,  when  SRIBLD  is  called  it  obtains  the 
filtered  data  from  AMTRK  corresponding  to  the  track  to  be  handed  over. 

If  this  is  the  first  time  SRIBLD  has  been  called  to  process  this  particu¬ 
lar  AMRAD  track,  it  builds  a  dedicated  OTDS  instance  and  initializes  it 
with  data  obtained  from  AMTRK.  Otherwise,  it  simply  reinitializes  the 
proper  dedicated  OTDS  instance  with  the  AMTRK  data.  SRIBLD  then  re¬ 
quests  a  time  for  transmission  of  a  track  pulse  by  placing  a  TPDS  in¬ 
stance  in  an  active  queue  with  the  desired  time.  The  TPDS  data  file  is 
a  volatile  file,  each  of  whose  instances  correspond  to  one  of  the  active 
HAPDAR  tracks.  The  instance  contains  a  track  pulse  transmission  time, 
a  pointer  or  address  of  the  OTDS  instance,  and  a  pointer  to  the  corres¬ 
ponding  instance  of  the  TROQ  data  file.  The  TROQ  data  file  contains  the 
data  required  to  form  the  track  beam  being  requested  through  TPDS. 

In  order  to  ensure  a  high  priority  for  this  handover  track  pulse 
request,  the  request  time  is  set  equal  to  the  time  of  validity  of  the 
data  in  AMTRK.  This  time  will  generally  be  slightly  in  the  past,  but 
will  be  honored  in  any  case  as  soon  as  possible,  SRIBLD  also  constructs 
part  of  the  track  order  contained  in  the  TROQ.  This  consists  of  setting 
some  pointers  in  TROQ,  setting  the  track/special  acquisition  indicator 
to  "track,"  the  type  of  command  to  "SRI  track,  and  the  waveform  to 
"long  range  track."  SRIBLD  then  returns  control  to  TRANFT,  which  then 
returns  control  to  BMDOS. 

At  an  appropriate  time  the  radar  management  function,  KRM,  per¬ 
forms  two  services.  First,  it  selects  and  schedules  radar  pulses; 
second,  it  builds  radar  orders  for  each  of  the  pulses.  These  radar 
orders  may  be  for  either  track,  verify,  or  search  pulses.  Only  the 
track  pulse  scheduling  function  interfaces  with  the  SRI  handover 


software . 
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KRM  examines  the  TPDS  data  file  to  determine  if  any  track  requests 
are  present.  If  so,  KRM  selects  the  instance  in  TPDS  with  the  earliest 
time  such  that  the  time  does  not  exceed  the  block  end  time  for  the  next 
block  of  radar  orders  to  be  scheduled.  If  there  is  a  valid  choice,  then 
KRM  detaches  the  instance  from  the  TPDS  queue  (i.e.,  flags  it  to  indi¬ 
cate  it  has  been  scheduled).  KRM  then  completes  the  corresponding  rad' r 
order  instance  in  TROQ .  This  includes  computation  of  such  quantities 
as  beam-pointing  information  and  estimated  range,  among  other  associated 
information.  In  order  to  perform  these  computations,  data  are  obtained 
from  the  corresponding  instance  of  OTDS .  KRM  then  puts  the  pointer  to 
the  TROQ  instance  it  has  just  completed  into  a  radar  order  pointer  queue. 
ROPQ .  ROPQ  is  a  data  file  consisting  simply  of  a  list  of  such  pointers 
for  the  radar  orders  scheduled. 

KRM  continues  reiterating  this  procedure  until  a  radar  order  block 
is  filled,  or  TPDS  is  empty  or  an  ineligible  request  is  encountered 
(i.e.  one  with  a  request  time  later  than  the  block  end  time).  KRM 
then  proceeds  to  examine  the  verify  and  search  requests,  if  the  block 
has  not  been  filled. 

After  completing  a  radar  order  block,  KRM  checks  the  required  radar 
duty  factor  for  the  scheduled  block.  If  the  radar  duty  factor  specifi¬ 
cation  is  exceeded,  KRM  simply  increases  the  block  duration.  At  this 
point  KRM  returns  control  to  the  BMDOS  system. 

After  KRM  has  been  executed,  the  data  link  control  function,  WLC, 
is  executed.  WLC  employs  a  set  of  routines  to  transmit  radar  orders 
through  the  radar  computer  interface  (RCI)  to  HAPDAR  and  receive  radar 
returns  generated  by  HAPDAR.  The  orders  transmitted  over  the  data  link 
are  passed  via  the  set  of  pointers  in  ROPQ.  The  data  link  software 
then  obtains  the  data  from  TROQ  (when  a  track  order  is  to  be  transmitted) 
and  converts  the  radar  orders  to  the  form  required  by  the  HAPDAR  data 


link.  Similarly,  the  data  of  the  returns  from  HAPDAR  are  converted  to 
the  proper  form  and  placed  in  a  unique  instance  in  the  radar  return 
queue,  RRQ .  RRQ  is  a  data  file  that  contains  the  raw  data  obtained  by 
HAPDAR.  When  the  data  link  software  completes  the  conversion  of  the  set 
of  returns,  the  RRQ  data  file  is  passed  to  the  Return  Preprocessing 
function  ARRP . 

ARRP  processes  the  returns  that  have  been  established  in  RRQ.  It 
first  determines  the  type  of  return  (i.e.,  search,  verify,  special 
acquisition,  or  track  return)  and  then  calls  one  of  several  appropriate 
return  processing  functions.  In  particular,  if  the  return  is  a  hand¬ 
over  return,  the  function  DTTSRI  is  called. 

DTTSRI  and  its  associated  subfunctions  filter  the  HAPDAR  data 
obtained  in  response  to  track  pulse  requests  for  the  two  dedicated 
track  channels.  If  a  valid  hit  is  not  obtained,  DTTSRI  simply  propagates 
the  state  and  covariance  up  to  the  current  time.  If  there  is  a  valid 
hit,  the  raw  data  contained  in  RRQ  in  conjunction  with  information  con¬ 
tained  in  TROQ  is  smoothed  into  the  data  in  OTDS ,  and  the  new  smoothed 
data  is  placed  into  OTDS.  In  addition  DTTSRI  requests  the  next  track 
pulse  by  placing  an  appropriate  TPDS  instance  into  the  active  queue. 

The  processing  completes  a  normal  cycle  when  KRM  is  executed  again  to 
build  and  schedule  the  next  radar  orders.  Once  every  second,  as  dis¬ 
cussed  above,  this  normal  cycle  is  reinitialized  when  TRANFT  calls 
QUECOR  and  SRIBLD. 
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DESCRIPTION  OF  AMRAD  MODIFICATIONS  FOR  TARGET  HANDOVER 
AND  CORRELATION  DEMONSTRATION 

The  Riverside  Research  Institute  ( RRI)  made  major  modifications  to 
the  AMRAD  equipment  to  support  the  handover  and  correlation  program. 
These  modifications  were  described  in  a  proposal  submitted  to  WSMR.12 
The  following  is  an  updated  abstract  from  the  proposal,  describing  the 
handover  system,  the  data  transmission  system,  and  the  synchronization 
and  timing  of  the  systems. 

A  .  System  Description 

The  equipment  configuration  to  provide  the  Phase  II*  AMRAD/IIAPDAR 
interface  is  shown  in  Figure  F-l.  The  implementation  of  the  Phase  II 
configuration  primarily  entailed  (1)  providing  an  additional  data  path 
between  DRTS  II  DAS  and  the  AMRAD/HAPDAR  interface  system,  (2)  modifi¬ 
cation  of  the  SDS  920  software  to  eliminate  the  prediction  algorithms 
and  to  add  the  Range  Tracker  II  data  handling  capability,  and  l 3) 
redesign  of  the  kineplex  data  format. 

The  additional  data  piths  required  that  signal  conditioning  and 
cable  driving  circuitry  be  added  in  the  DAS  II  for  22  bits  of  range 
information,  7  bits  of  precursor  A/D  converter  counts,  and  3  bits  of 
track  status  information.  The  MILGO  chassis  formerly  used  as  the 
chain  storage  register  was  completely  redesigned  to  accept  and  store 
the  22  bits  of  secondary  range  data.  The  MILGO  phase  and  amplitude 


Phase  T  is  described  in  Reference  2. 
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buffer  was  modified  to  accept  and  store  the  seven  bits  of  precursor  A/D 
counts.  The  transmitter  control  chassis  was  modified  to  accept  and  gate 
the  track  status  information  for  both  trackers. 

The  prediction  algorithm  was  eliminated,  and  logic  to  store,  record, 
and  output  raw  secondary  tracker  data  was  provided.  Signal  amplitude 
data  are  averaged  for  each  tracker  and  output  to  the  kineplex  in  a  for¬ 
mat  suitable  for  setting  AGC  levels  at  HAPDAR.  Raw  range  data  are  out¬ 
put  to  the  kineplex  in  a  20-bit  binary  format. 

The  kineplex  data  format  was  a  slightly  modified  version  of  the 
Phase  I  formats.  The  format  for  each  tracker  was  identical.  The  specific 
tracker  with  which  the  data  are  associated  was  identified  by  a  code  in 
channel  4  of  frame  1.  Sync  identification  transmitted  in  frame  13  of 
the  Phase  I  format  was  replaced  by  signal  level  information.  The 
time-of-day  at  which  the  data  was  valid  was  contained  in  frames  5  and  9. 

The  implementation  of  format  changes  involved  in  frames  1  through 
12  required  only  minor  software  modifications.  However,  since  frame  13 
was  under  hardware  control,  a  new  addressable  holding  register  and  gating 
control  was  required.  A  gating  function  was  designed  to  allow  either 
the  hardware  controlled  sync  identification  or  the  software  controlled 
signal  strength  information  to  be  manually  selectable,  so  as  to  provide 
flexibility  during  the  development  of  the  Phase  II  interface. 

B  .  Kineplex  Data  Description 

The  kineplex  message  format  was  identical  for  both  DRTS  I  and 
DRTS  II  tracker  information  and  is  shown  in  Figure  F-2.  Definitions 
of  items  in  the  data  are  tabulated  below. 


Item 


Definition 


Tracker  identification 


Range  (R^  -  R2Q) 


Azimuth  (A^  -  A^) 


Elevation  (E^  -  E^) 


Time  (T  -  T^) 


Tracker  identification  is  contained 
in  channels  3  and  4  of  frame  1  . 

1=1=  AMRAD 

I  =  0  =  PAS 

I  =  1  =  DRTS  II  tracker 
2 

I  =  0  =  DRTS  I  tracker 
2 

Range  information  is  contained  in 
frames  1  through  4 . 

19 

R  =  MSB  =  1 .4989644  X  2  meters 

1  0 
R  =  LSB  =  1 .4989644  X  2  meters 
20 

Azimuth  information  is  contained  in 
frames  6  through  8. 

A  =  6400  x  2  1  mils  (180c) 

*  -17  „  -16 
A  =  6400  x  2  mils  (180  X  2  ) 

17 

Elevation  information  is  contained  in 
frames  10  through  12 . 

E  =  6400  v  2  1  mils  (180°) 

1  -17  „  -16 

E  =  6400  X  2  mils  (180  X  2  ) 

17 

Time  of  day  at  which  data  was  valid 
(referenced  in  GMT  and  contained  in 
frames  5  and  9)  . 

T  =2  seconds 
1 

T  =1  second 

2 

T  =1x2  milliseconds  (512  ms) 

3  0 

T  =1x2  milliseconds 
12 

T  through  T  contain  a  binary  count 
3  1 2 

of  milliseconds  that  truncates  to 
zero  after  a  count  of  999  milliseconds 


Received  power  (P 


Tracker  status  (S^ 


Fram^  15  was  hardwired 
identical  information, 


Average  received  power,  relative  to 
AMRAD  received  precursor,  is  con¬ 
tained  in  frame  13.  -  Pg  1S  the 

binary  magnitude  of  AMRAD  received 
power  (in  dBm)  above  the  predefined 
HAPDAR  minimum  discernible  signal 
where: 

5 

p  =  MSB  =  1  .0  v  2  (dBm) 

1  0 
p  =  LSB  =  1 .0  v  2  (dBm) 

6 

The  status  of  the  tracker  identified 
in  frame  1  is  contained  in  frame  14. 
The  valid  codes  are  as  follows: 


0  0  manual 

0  1  acquisition 

1  1  autotrack 

to  contain  all  zeros.  Channels  7  and  8  contain 
which  is  all  ones  . 
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IBM  360/65  computer  using  special  BMD  software.  The  two  radars  were  separated  by 

about  ten  miles.  .  .  .  „  .  .. 

This  report  describes  the  software  developed  for  these  demonstrations  and  the 

tests  that  were  carried  out  to  demonstrate  target  transfer  from  one  radar  to  an- 
other  and  target  track  association  or  correlation  between  independent  tracks  of  tie 

two  radars  . 
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